Error cURL 60 a WordPress: problema amb el certificat SSL — diagnòstic i reparació segurs

Què importa primer: La connexió de sortida HTTPS va arribar a un servidor, però la validació del certificat ha fallat. La causa pot ser un certificat caducat, faltant el nom de servidor intermedi, incorrecte, paquet CA obsolet o tràfic interceptat.

Què indica realment aquest símptoma

Això és un error de confiança, no un temps d’espera de xarxa genèric. Desactiva sslverify fa que l’advertiment desaparegui eliminant la protecció que impedeix les respostes de l’home al mig.

Recull proves abans de canviar res

• Registra el nom del servidor de destí i l’error complet del certificat.
• Inspecciona la cadena de certificats des del servidor WordPress, no només un navegador.
• Comprova la data del servidor, el paquet CA i les versions OpenSSL/cURL.
• Confirmar que cap intermediari o aparell de seguretat està substituint el seu propi certificat.

Causes més habituals

• Cadena remota incompleta: l’origen no serveix el certificat intermedi necessari per arribar a una arrel de confiança.
• Certificat caducat o desfasat: El certificat està fora del seu període de validesa o no cobreix el nom del servidor sol· licitat.
• Magatzem de CA antiquat: La imatge o sistema operatiu servidoring no té un paquet de confiança actual.
• Intercepció TLS: Un intermediari presenta un certificat privat en el que el servidor no confia.

Seqüència segura de diagnòstic i reparació

1. Repareu la cadena de certificats en el servei remot quan ho controleu.
2. Actualitza els certificats CA del sistema operatiu i reinicieu el servei PHP pertinent.
3. Usa el nom de servidor correcte i elimineu redirecionaments a servidors no coberts pel certificat.
4. Torna a provar amb la verificació habilitada i documenta qualsevol instal· lació privada de CA requerida.

Com distingir entre les causes probables

No tractis Cadena remota incompleta i Certificat caducat o desfasat com a causes equivalents. L’origen no serveix al certificat intermedi necessari per a arribar a una arrel de confiança. En canvi, el certificat està fora del seu període de validesa o no cobreix el nom de servidor sol· licitat. Per a distingir- les, usa aquestes dues comprovacions: Registra el nom del servidor de destí i l’error complet del certificat; i inspecciona la cadena de certificats des del servidor WordPress, no només un navegador. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada – Repareu la cadena de certificats en el servei remot quan ho controleu- o si heu de conservar l’estat actual i ampliar la recerca.

En un lloc de WordPress en producció, repeteix la petició que falla mentre comprova una pàgina que funciona correctament i l’àrea d’administració. Un error aïllat en una ruta requereix un rollback més acotat que un problema que afecta PHP, la base de dades o totes les peticions. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.

Què no has de fer

Mai envieu un filtre permanent que estiguibleixi sslverify a false. Exposa actualitzacions, llicències, webhooks i tràfic API a manipulació.

Com verificar la reparació

• El servidor valida la cadena completa amb el nom de servidor previst.
• WordPress realitza la sol · licitud de sortida amb la verificació SSL habilitada.
• No queda cap avís de certificat a Site Health o a l’plugin registres.

Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.