Blog

Quan es parla de certificats SSL/TLS, moltes empreses pensen automàticament en la seva pàgina web.

En el cadenat del navegador, en l’ecommerce, en l’àrea privada o en el formulari de contacte.

I és lògic. La web acostuma a ser l’entorn més visible on un certificat caducat o mal configurat genera un impacte immediat.

Però els certificats SSL/TLS no només protegeixen pàgines web.

També poden intervenir en serveis crítics relacionats amb el correu corporatiu: SMTP, IMAP, POP, webmail, relays interns, gateways de seguretat, connectors híbrids, balancejadors o servidors intermedis.

I aquest punt sovint queda fora del radar.

Moltes empreses revisen el certificat del seu domini principal, però no sempre saben quins certificats participen en el funcionament real del seu correu electrònic.

El problema és que, quan un d’aquests certificats caduca o està mal configurat, l’impacte pot afectar usuaris, aplicacions, integracions i processos interns.

Per això, el correu corporatiu també hauria de formar part de qualsevol estratègia seriosa de gestió de certificats SSL/TLS.

El correu no depèn d’una sola connexió

Per a molts usuaris, el correu electrònic és simplement Outlook, Gmail, Apple Mail, Thunderbird o una interfície web des de la qual envien i reben missatges.

Però al darrere, el correu corporatiu pot dependre de diverses connexions.

Un usuari pot consultar la seva bústia mitjançant IMAP o POP. Pot enviar missatges a través d’SMTP. Una empresa pot tenir un webmail propi. Una aplicació interna pot enviar notificacions mitjançant un relay. Un ecommerce pot enviar confirmacions de comanda. Un CRM pot enviar correus comercials. Un sistema de suport pot generar avisos automàtics. Un gateway pot analitzar missatges abans de lliurar-los.

Cadascuna d’aquestes peces pot formar part del flux del correu.

I algunes poden necessitar certificats SSL/TLS per establir connexions segures.

Per això, encara que el correu sembli centralitzat en una sola plataforma, en la pràctica pot dependre d’una infraestructura més àmplia.

Quin paper tenen els certificats SSL/TLS en el correu

Els certificats SSL/TLS permeten protegir connexions entre sistemes.

En el context del correu electrònic, això pot aplicar-se quan un usuari es connecta a un servidor per consultar els seus missatges, quan una aplicació envia correus mitjançant SMTP, quan un webmail es carrega al navegador, quan un relay accepta missatges des de sistemes interns o quan un gateway de seguretat es comunica amb altres servidors.

En tots aquests casos, TLS ajuda a xifrar la connexió i a reduir el risc que la informació viatgi exposada.

Això no s’ha de confondre amb altres mecanismes de seguretat del correu, com SPF, DKIM, DMARC o BIMI.

SPF, DKIM i DMARC ajuden a autenticar el domini i a reduir la suplantació. BIMI ajuda a reforçar la identitat visual de la marca en clients compatibles.

TLS, en canvi, se centra a protegir la connexió per la qual circula la informació.

Són capes diferents.

I precisament per això convé no oblidar-ne cap.

Una empresa pot tenir ben configurada l’autenticació del seu domini i, tot i així, tenir certificats SSL/TLS oblidats en serveis de correu, relays, gateways o aplicacions que també formen part de la seva operativa diària.

On poden estar els certificats del correu corporatiu

Els certificats SSL/TLS associats al correu poden estar en més llocs del que sembla.

Poden estar en servidors SMTP utilitzats per a l’enviament de missatges. També en serveis IMAP o POP, que permeten consultar bústies des de clients de correu. Poden estar al webmail, si l’empresa ofereix accés al correu des del navegador.

També poden estar en relays interns que reben missatges des d’aplicacions corporatives, gateways de seguretat que filtren el trànsit de correu, appliances antispam, eines de xifratge, sistemes d’arxivat, balancejadors, firewalls, connectors híbrids o servidors intermedis.

En empreses amb infraestructures més complexes, aquests certificats poden estar repartits entre diferents entorns.

Part del correu pot dependre de Microsoft 365 o Google Workspace. Una altra part pot continuar vinculada a servidors propis, proveïdors externs, aplicacions internes, serveis cloud, eines de màrqueting, CRMs, ERPs o plataformes de suport.

El resultat és que el correu corporatiu no sempre depèn d’un únic punt.

I els certificats que intervenen en aquest ecosistema tampoc.

Què pot passar si un certificat del correu caduca

Quan caduca un certificat associat al correu corporatiu, l’impacte pot variar segons el servei afectat.

En alguns casos, els usuaris poden veure avisos de seguretat en el seu client de correu. El sistema pot indicar que el certificat no és vàlid, que ha caducat, que no coincideix amb el nom del servidor o que la connexió no és fiable.

Això pot generar dubtes, consultes a l’equip tècnic i pèrdua de confiança en el servei.

En altres casos, el problema pot afectar l’enviament de correus.

Una aplicació pot deixar d’enviar notificacions. Un ecommerce pot no enviar confirmacions de comanda. Un CRM pot fallar en l’enviament de missatges. Un sistema d’alertes pot deixar de lliurar avisos importants. Una plataforma de suport pot no enviar actualitzacions als clients.

També pot afectar la recepció, el filtratge o l’encaminament del correu.

Un gateway pot rebutjar connexions. Un relay pot deixar d’acceptar missatges. Un servidor intermedi pot generar errors. Una integració pot quedar interrompuda.

El més complex és que, moltes vegades, el problema no s’identifica immediatament com una incidència de certificat.

Des de fora, pot semblar una fallada del client de correu, un problema de configuració SMTP, una caiguda del proveïdor, un error d’autenticació o una incidència de connectivitat.

Però l’origen pot estar en un certificat SSL/TLS caducat, mal instal·lat o no reconegut correctament.

Què passa quan caduca un certificat SSL/TLS no sempre es limita a una web: també pot afectar serveis interns, aplicacions i fluxos crítics com el correu corporatiu.

El problema no sempre és la caducitat

La caducitat no és l’únic risc.

Un certificat pot estar vigent, però no estar correctament configurat.

Pot haver-se emès per a un nom que no coincideix amb el servidor que fan servir els clients de correu. Pot faltar la cadena intermèdia. Pot haver-se instal·lat al servidor principal, però no al relay. Pot haver-se renovat, però no desplegat al gateway. Pot continuar actiu un certificat antic en una capa intermèdia.

En aquests casos, la incidència pot ser parcial.

Alguns usuaris poden connectar-se sense problemes, mentre que altres reben errors. Una aplicació pot enviar correus correctament, però una altra no. El webmail pot funcionar, però el client d’escriptori pot mostrar avisos. El servidor principal pot estar bé, però un sistema intermedi pot continuar utilitzant un certificat obsolet.

Aquest tipus de problemes són especialment incòmodes perquè no sempre generen una caiguda clara i fàcil de detectar.

De vegades el correu funciona “a mitges”.

I això complica el diagnòstic.

Per què aquests certificats solen quedar fora de l’inventari

Els certificats SSL/TLS vinculats al correu solen quedar fora de l’inventari per una raó senzilla: no sempre són visibles.

El certificat d’una web pública es pot comprovar fàcilment des del navegador. Si falla, l’avís és evident. Si caduca, l’impacte acostuma a detectar-se ràpidament.

Però els certificats associats al correu poden estar en serveis menys exposats.

Un servidor SMTP intern. Un relay que només fan servir determinades aplicacions. Un gateway configurat fa anys. Un connector híbrid. Un servei IMAP utilitzat per pocs usuaris. Un sistema d’enviament automàtic. Una eina externa integrada amb la infraestructura de l’empresa.

A més, el correu corporatiu acostuma a estar repartit entre diverses responsabilitats.

Hi pot intervenir l’equip de sistemes, l’equip de seguretat, el proveïdor d’allotjament, el proveïdor de correu, el departament de suport, un integrador extern o el responsable d’una aplicació concreta.

Quan no hi ha una visió centralitzada, és fàcil que alguns certificats quedin documentats en fulls de càlcul antics, en panells diferents o directament en configuracions que ningú revisa fins que fallen.

El problema no sol ser la manca d’importància del correu.

El problema és la manca de visibilitat sobre totes les peces que el sostenen.

El risc augmenta en entorns híbrids

Moltes empreses utilitzen plataformes com Microsoft 365 o Google Workspace per gestionar el seu correu principal.

Això pot simplificar una part important de l’operativa, però no sempre elimina tots els certificats SSL/TLS relacionats amb el correu.

Una empresa pot mantenir relays interns per a aplicacions corporatives, gateways de seguretat externs, connectors híbrids, servidors propis per a determinats serveis o plataformes de màrqueting, CRM, ERP, ticketing o ecommerce que envien correus mitjançant SMTP.

En aquests entorns, alguns certificats poden estar gestionats pel proveïdor principal. Altres poden dependre de l’equip intern. Altres poden estar en mans de tercers. Altres poden estar instal·lats en sistemes heretats que continuen sent necessaris per a processos concrets.

Per això, assumir que “el correu és al núvol” no sempre significa que tots els certificats associats al correu estiguin controlats.

En molts casos, continuen existint peces intermèdies que necessiten supervisió.

Aquesta realitat és similar al que passa amb la gestió de certificats SSL/TLS en entorns cloud i multi-cloud: com més distribuïda està la infraestructura, més important és tenir visibilitat centralitzada.

Com ajuda CertGuardian a gestionar certificats vinculats al correu

Per controlar els certificats SSL/TLS associats al correu corporatiu, el primer pas és tenir inventari.

Saber quins certificats existeixen, on estan instal·lats, quin servei protegeixen, quan caduquen, qui els gestiona, quins sistemes en depenen i si s’han renovat i desplegat correctament.

Amb CertGuardian, les empreses poden centralitzar la gestió dels seus certificats SSL/TLS, monitorar-ne l’estat, configurar alertes, automatitzar renovacions i mantenir traçabilitat sobre els processos de renovació, instal·lació i canvi.

Això ajuda a evitar que els certificats vinculats al correu quedin fora del radar.

Especialment en entorns amb SMTP, IMAP, POP, webmail, relays, gateways, connectors, servidors intermedis, proveïdors externs o infraestructures híbrides.

L’avantatge no és només renovar certificats.

És tenir una visió més completa de tots els certificats que formen part de la infraestructura digital de l’empresa, inclosos aquells que no són visibles des d’una web pública, però que poden afectar serveis crítics com el correu corporatiu.

Per això, automatitzar certificats SSL/TLS sense perdre el control també implica mantenir inventari, monitoratge, alertes i traçabilitat sobre certificats que no sempre són evidents.

Centralitza la gestió de certificats SSL/TLS amb CertGuardian.

El correu també forma part de la gestió SSL/TLS

El correu electrònic és un dels serveis més crítics per a qualsevol empresa.

S’utilitza per comunicar-se amb clients, proveïdors, empleats, plataformes, aplicacions i sistemes interns.

Per això, la seva seguretat i disponibilitat no depenen només de filtres antispam, autenticació del domini o polítiques de protecció davant del phishing.

També depenen de les connexions segures que permeten enviar, rebre, consultar, filtrar i processar missatges.

I aquestes connexions poden recolzar-se en certificats SSL/TLS.

Si aquests certificats queden fora de l’inventari, caduquen o es configuren malament, l’impacte pot arribar a usuaris, aplicacions, relays, gateways, integracions i processos de negoci.

Per això, el correu corporatiu també ha de formar part de la gestió centralitzada de certificats SSL/TLS.

Perquè els certificats no només protegeixen la web.

També sostenen serveis que moltes empreses utilitzen cada dia sense veure’ls.