Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Smtp I Php Mail

Els errors de certificat TLS impedeixen l’enviament SMTP de WordPress

Repara TLS revisant hostname, SNI, hora, confiança CA, cadena, intercepció i port sense desactivar la verificació.

TLS protegeix les credencials SMTP i el missatge durant el trajecte entre WordPress i el proveïdor. Un error de certificat significa que el servidor no ha pogut verificar la identitat o la cadena de confiança de l’endpoint. Desactivar la comprovació converteix un error visible en una connexió insegura.

Captura l’error precís i corregeix-ne la causa.

Registra l’error del certificat

Executa una connexió controlada i anota el hostname SMTP, el port, el mode de xifratge, l’hora i l’error amb les dades ocultes. Distingeix nom no coincident, certificat caducat, emissor desconegut, cadena incompleta i error de handshake.

No comparteixis un transcript SMTP detallat amb autenticació. El certificat és públic, però el log pot revelar usuaris, adreces internes o contingut.

Atura les repeticions si el proveïdor aplica protecció de login.

Utilitza el hostname oficial

El certificat s’expedeix per a noms concrets. Connectar a una IP, un hostname antic o mail.elteudomini.com sense cobertura pot fallar encara que arribi al servidor correcte.

Utilitza l’endpoint exacte del proveïdor. Confirma que DNS el resol com s’espera i que /etc/hosts no el desvia.

Comprova també que el client envia SNI amb el hostname. En servidors amb diversos serveis TLS a la mateixa IP, ometre’l pot presentar el certificat predeterminat d’un altre domini.

No desactivis la validació del nom per conservar un àlies no oficial.

Fes coincidir el port i TLS

El 587 sol començar en text i pujar mitjançant STARTTLS; el 465 acostuma a esperar TLS des de l’inici. Utilitzar TLS implícit contra STARTTLS, o al contrari, pot semblar un error de certificat.

Comprova com etiqueta el plugin “TLS”, “SSL” i “auto”, perquè no tots utilitzen els mateixos noms. Segueix la configuració vigent del proveïdor.

No enviïs credencials abans del xifratge quan el servei exigeix TLS.

Comprova l’hora del servidor

La validesa depèn del rellotge. Una data molt incorrecta pot fer que un certificat vàlid sembli futur o caducat.

Compara l’hora del sistema amb una font fiable i confirma la sincronització. Corregeix-la mitjançant l’administrador de l’allotjament; canviar la zona horària de WordPress afecta continguts i logs, no TLS.

Repeteix la prova amb una hora nova després de sincronitzar.

Actualitza el magatzem de CA

Un bundle d’autoritats antic o una instal·lació PHP/OpenSSL obsoleta pot no confiar en una cadena actual. Revisa les versions i el fitxer CA que utilitza el handler web.

Aplica actualitzacions compatibles del sistema i del panell mitjançant el manteniment previst. No descarreguis bundles aleatoris ni fixis manualment el certificat leaf, que caducarà.

PHP per terminal i PHP-FPM poden utilitzar configuracions diferents; prova des de l’entorn de WordPress.

Inspecciona la cadena presentada

Un administrador pot revisar l’endpoint sense credencials:

openssl s_client -connect smtp.example.net:465 
  -servername smtp.example.net -showcerts

Per a un proveïdor que documenti STARTTLS a 587, afegeix -starttls smtp. Comprova el resultat, els noms, l’emissor i les dates.

Revisa que es lliuri tota la cadena intermèdia, no només el certificat final. Un navegador pot descarregar intermediaris que falten mentre OpenSSL o PHP rebutgen la mateixa cadena.

Substitueix l’exemple només per l’endpoint oficial.

Busca intercepció o proxies antics

Un dispositiu de seguretat, proxy sortint o filtre de l’allotjament pot presentar el seu propi certificat. Compara l’emissor i l’endpoint amb la documentació.

Si hi ha inspecció TLS autoritzada, el servidor necessita la cadena corporativa gestionada i una decisió documentada. No confiïs silenciosament en un certificat desconegut.

Revisa també IPv6 i si diferents IP presenten cadenes inconsistents.

Demostra un lliurament segur

Després de corregir el nom, el mode, l’hora o la confiança, confirma el handshake amb la verificació activada. Envia després una prova del plugin i una altra del formulari real.

Rastreja acceptació, arribada final i SPF, DKIM i DMARC. Elimina els logs temporals.

Demana ajuda urgent si el certificat pertany a un altre servei, el trust store està obsolet o hi intervé un intermediari. Comparteix noms i errors amb dades ocultes, mai credencials SMTP.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència