Quando durante l'invio tramite IncaMail MGI appare il messaggio di errore «535 5.3.2 Relaying denied, no client certificate», nella maggior parte dei casi ciò indica un problema di configurazione sul connettore outbound o di invio – non che sia stato installato un certificato errato, che sia necessario un certificato aggiuntivo o che per ogni singolo utente sia richiesto un certificato client separato.
Nota: Questo errore può verificarsi in alcuni casi anche se il certificato viene presentato correttamente, ma non contiene la clientAuth EKU. Se questo è il vostro caso, vi preghiamo di leggere il seguente articolo: Rinnovo del certificato e clientAuth EKU – Impatti su IncaMail MGI
Cosa significa questo errore?
Il messaggio di errore indica che il server IncaMail non ha ricevuto un certificato client valido durante l'instaurazione della connessione. Le possibili cause sono le seguenti:
- Il certificato non è stato trovato sul connettore outbound.
- Il certificato non viene presentato correttamente.
- Il Common Name (CN) del certificato sul connettore outbound non corrisponde al CN sul connettore inbound.
Cosa dovrebbe essere verificato?
Procedete con i seguenti punti in ordine per restringere la causa:
1. STARTTLS e Autenticazione Mutua
Assicuratevi che sul vostro server di posta siano attivati i seguenti elementi:
- STARTTLS per la comunicazione SMTP sulla porta 25
- Autenticazione Mutua (detta anche «TwoWay-Authentication») per la crittografia TLS – sia per le connessioni in ingresso (inbound) che in uscita (outbound)
2. Certificato root SwissSign nel Truststore
Il certificato root SwissSign del certificato del server IncaMail deve essere inserito nel Truststore del vostro server di posta o gateway di posta, affinché la catena di fiducia verso IncaMail possa essere stabilita.
3. Certificato valido sul connettore outbound
Verificate che sul connettore outbound o di invio sia installato e attivo il certificato corretto e valido.
4. Certificato nel «ruolo client»
Il certificato deve essere presentato esplicitamente nel ruolo client sul connettore outbound. Assicuratevi che l'«Autenticazione certificato client» sia abilitata sul connettore.
5. Ordine della catena di certificati
La catena di certificati deve essere presentata nell'ordine corretto:
Certificato client → Certificato intermedio → Certificato root
Un ordine errato può causare il mancato riconoscimento della catena da parte del server IncaMail.
6. Corrispondenza del CN sui connettori inbound e outbound
Il Common Name (CN) del certificato sul connettore outbound (invio) deve corrispondere al CN registrato nel portale di gestione IncaMail MGI per la direzione di invio. Verificate anche che il CN del connettore inbound (ricezione) sia inserito correttamente.
I CN possono essere visualizzati e modificati nel portale di gestione MGI: 👉 Mail Gateway Integration – Portale di gestione
7. Certificato predefinito del server Exchange
Se utilizzate Microsoft Exchange: verificate che il certificato predefinito (Default Certificate) del server Exchange sia ancora attivo e non disabilitato. Un certificato predefinito ancora attivo può causare che Exchange utilizzi il certificato sbagliato per la comunicazione SMTP, anziché quello configurato per IncaMail.
Riepilogo della checklist
| Punto di controllo | Cosa considerare |
|---|---|
| STARTTLS / Autenticazione Mutua | Attivata su inbound e outbound, porta 25 |
| Certificato root SwissSign | Inserito nel Truststore del server di posta |
| Certificato sul connettore outbound | Installato correttamente e attivo |
| Ruolo client | «Autenticazione certificato client» attivata |
| Catena di certificati | Ordine: Client → Intermedio → Root |
| Corrispondenza CN | CN sul connettore outbound = CN nel portale MGI (direzione invio) |
| Certificato predefinito Exchange | Disabilitato, se presente |