Se la vostra azienda utilizza IncaMail tramite l'integrazione Mail Gateway (MGI) e un certificato è stato rinnovato, può accadere che l'invio tramite IncaMail improvvisamente non funzioni più. Questo articolo spiega perché ciò accade e quali soluzioni sono disponibili.
Contesto: cos’è la clientAuth EKU?
L'Extended Key Usage (EKU) è un campo del certificato che definisce per quali scopi un certificato può essere utilizzato. La clientAuth EKU (Object Identifier: 1.3.6.1.5.5.7.3.2) indica che il certificato può essere utilizzato per la autenticazione del client - cioè per identificare il vostro mail server nei confronti di un altro sistema (in questo caso la piattaforma IncaMail).
IncaMail MGI utilizza la autenticazione TLS reciproca (Mutual TLS): durante l'instaurazione della connessione, la piattaforma IncaMail verifica il certificato del vostro mail gateway. Se questo certificato non contiene la clientAuth EKU, la connessione viene rifiutata e l'invio fallisce.
Quando si verifica il problema?
Il problema si presenta tipicamente quando un certificato esistente viene rinnovato e il nuovo certificato contiene, rispetto al precedente, campi EKU diversi o limitati. Ciò può accadere se:
- il fornitore del certificato ha modificato la configurazione standard,
- è stato utilizzato un prodotto di certificato o un modello di certificato diverso,
- il certificato è stato emesso internamente e la clientAuth EKU non è stata esplicitamente impostata.
In questi casi, l'invio tramite IncaMail funzionava perfettamente prima del rinnovo del certificato - e dopo il rinnovo, senza modifiche evidenti alla configurazione, smette improvvisamente di funzionare.
Come riconoscere il problema?
Se l'invio non è più possibile dopo il rinnovo del certificato, verificate innanzitutto i messaggi di errore nei log del vostro mail gateway. Indicazioni tipiche sono:
- errori di handshake TLS durante la connessione a IncaMail
- messaggi di errore relativi alla validazione o all'autenticazione del certificato. Un tipico messaggio di rimbalzo potrebbe essere:
5.3.2 Relaying denied, no client certificate - l'invio di messaggi IncaMail fallisce mentre l'invio di altre email funziona regolarmente
Per verificare se il vostro certificato contiene la clientAuth EKU, potete ispezionare il certificato nella vostra gestione certificati o utilizzare uno strumento come OpenSSL:
openssl x509 -in certificato.pem -text -noout | grep -A1 "Extended Key Usage"
Un risultato valido contiene la voce TLS Web Client Authentication. Se questa voce manca, il certificato non supporta la clientAuth EKU. Se avete dubbi nell'interpretazione dei risultati, vi preghiamo di inviarci il vostro certificato in formato PEM.
Soluzioni possibili
Esistono due modi per risolvere il problema:
Opzione 1: installare un certificato con clientAuth EKU (consigliato)
La soluzione più duratura è installare un certificato che contenga esplicitamente la clientAuth EKU. Rivolgetevi al vostro fornitore di certificati o all’ente PKI interno e assicuratevi che il nuovo certificato includa le seguenti EKU:
-
TLS Web Server Authentication (
1.3.6.1.5.5.7.3.1) -
TLS Web Client Authentication (
1.3.6.1.5.5.7.3.2)
Se il vostro provider non fornisce un certificato di questo tipo, possiamo crearne uno per voi - senza costi aggiuntivi. Per farlo, dovete generare un CSR e inviarlo al nostro team di supporto. Vi emetteremo quindi un certificato speciale valido per 1 anno. Questo certificato dedicato è emesso direttamente da IncaMail e può quindi essere utilizzato esclusivamente per l'autenticazione presso i server IncaMail. Non è riconosciuto da altri servizi.
I requisiti per il CSR sono i seguenti:
- Deve essere codificato in PEM
- La dimensione massima deve essere 16 kB
- La firma può essere RSA: 2048–8192 o ECDSA P-256, P-384, P-521
Non verifichiamo né consideriamo: Subject / SAN / EKU richieste - queste saranno aggiunte da noi al certificato.
Se disponete già di un certificato conforme, dovete installarlo sul vostro mail server.
Una volta installato il certificato corretto sul vostro mail server e, se necessario, aggiornate i dati CN nel portale di gestione IncaMail MGI, l'invio dovrebbe tornare a funzionare senza problemi.
Nota: Se il Common Name (CN) del nuovo certificato è cambiato, deve essere aggiornato nel portale di gestione MGI sotto Impostazioni → Mail Gateway Integration.
Opzione 2: abilitare l'autenticazione del server
Se non è possibile ottenere rapidamente un certificato adatto con clientAuth EKU, oppure non è possibile installare un certificato client dedicato sul vostro mail server, IncaMail offre una soluzione alternativa che bypassa l'autenticazione client e si basa esclusivamente sull'autenticazione del server. In questa modalità, IncaMail verifica solo il certificato del server ricevente, non quello del client mittente.
In alcuni casi questa opzione è l'unica soluzione disponibile, ad esempio:
- Exchange Online (O365)
- SeppMail
- Hornetsecurity
- HostStar
Per abilitare questa soluzione alternativa, inviate una richiesta di supporto indicando il dominio interessato.
Riepilogo
| Situazione | Azione consigliata |
|---|---|
| Il nuovo certificato non contiene la clientAuth EKU |
Opzione 1: richiedere e installare un certificato con clientAuth EKU dal fornitore Opzione 2: richiedere e installare un certificato tramite il supporto IncaMail inviando un file CSR |
| Il CN del nuovo certificato è cambiato | Aggiornare il CN nel portale di gestione MGI |
| Non è disponibile un certificato adeguato o non è possibile installarlo | Contattare il supporto per abilitare la soluzione alternativa di autenticazione server |
Avete bisogno di assistenza?
Se non siete sicuri che il vostro certificato contenga la clientAuth EKU o se desiderate attivare la soluzione alternativa, il supporto IncaMail è a vostra disposizione:
👉 Invia una richiesta di supporto
Vi preghiamo di indicare nella richiesta il dominio interessato in modo da poter verificare la vostra configurazione in modo mirato.