La sicurezza di Expressway si regge su una PKI ben progettata: ogni nodo espone la propria identità tramite un server certificate e valida i peer grazie alla lista di trusted CA certificate. Capire questo ciclo è indispensabile sia per il deployment MRA (Mobile and Remote Access) sia per il B2B.
Il ciclo CSR → CA → certificato server
Il processo parte sempre sul singolo Expressway (mai copiando chiavi tra nodi):
- Generazione della CSR (
Maintenance > Security > Server certificate > Generate CSR). Expressway crea la coppia di chiavi e mantiene la private key localmente: non deve mai lasciare il box. - Firma da parte della CA (interna Windows/enterprise o pubblica). Per MRA verso Internet è fortemente consigliata una CA pubblica sull’Expressway-E, così Jabber e i client mobile la fidano nativamente.
- Upload del certificato firmato più l’intera chain (root + intermediate) nella trust list.
Il CN e le SAN vengono decisi in fase di CSR: se ti accorgi dopo che manca una SAN, devi rigenerare la CSR e rifirmare, non basta modificare la configurazione.
Server certificate vs trust (CA) certificate
| Elemento | Cosa contiene | A cosa serve |
|---|---|---|
| Server certificate | Identità del nodo (CN + SAN) + private key | Presentarsi ai peer durante l’handshake TLS |
| Trusted CA certificate | Root e intermediate CA | Validare il certificato che il peer presenta |
Errore concettuale frequente: pensare che caricare il server certificate basti. Se la CA che ha firmato il certificato del peer non è nella trust list, la validazione fallisce anche con un certificato perfettamente valido.
Quali SAN inserire nel CSR
Le SAN sono la parte che l’esame verifica di più. A seconda del ruolo del nodo servono:
- FQDN di ciascun peer del cluster (una SAN per ogni membro).
- FQDN del cluster (il nome DNS che risolve verso tutti i peer), altrimenti la validazione verso il cluster name fallisce.
- Domini MRA /
_collab-edge: sull’Expressway-E vanno inseriti i domini usati nel record SRV_collab-edge._tls.<dominio>; è il nome contro cui Jabber verifica il certificato in fase di discovery. - Registration domains di Unified CM e domini di federazione XMPP, dove applicabili.
- Phone security profile names (in formato FQDN): necessari come SAN sull’Expressway-C quando si registrano endpoint in modalità secure/encrypted via MRA. Se mancano, la registrazione TLS del telefono fallisce.
La schermata di generazione CSR di Expressway propone esplicitamente queste categorie (Unified CM registrations, XMPP, collab-edge): vanno selezionate in base al servizio attivo.
Mutual TLS sulla traversal zone C–E
La Unified Communications traversal zone tra Expressway-C ed Expressway-E usa TLS con autenticazione mutua obbligatoria sulla porta 7001. Non è opzionale come su una generica traversal zone: entrambi i lati devono presentare e validare un certificato.
Meccanismo di validazione reciproca:
- Il TLS verify mode deve essere On su entrambi i nodi.
- Il TLS verify subject name configurato sulla zona deve corrispondere a CN o SAN del certificato del peer. Sull’Expressway-C punta al nome dell’Expressway-E; sulla traversal server zone dell’Expressway-E punta al nome dell’Expressway-C.
- Ogni nodo deve avere nella propria trust list la CA che ha firmato il certificato dell’altro. In lab spesso C ed E usano CA diverse (E pubblica, C interna): serve caricare entrambe le chain incrociate.
Se questa mutua validazione fallisce, la traversal zone resta Failed/TLS negotiation error e MRA non funziona, pur essendo la connettività di rete corretta.
Trappole tipiche d’esame
- SAN mancante per il cluster o per un peer → in scenario di cluster, la validazione verso il cluster FQDN fallisce anche se ogni singolo peer è raggiungibile: rigenera la CSR includendo cluster name e tutti i peer FQDN.
- Dominio
_collab-edgeassente nelle SAN dell’Expressway-E → Jabber esterno completa la SRV discovery ma rifiuta il certificato: aggiungi il dominio MRA come SAN sull’E. - Mismatch CN/SAN vs TLS verify subject name sulla traversal zone → mutual TLS fallita: allinea il verify subject name esatto a un CN/SAN presente sul certificato del peer.
- CA del peer non nella trust list → handshake fallito nonostante certificati validi: la risposta è caricare root+intermediate della CA che ha firmato il peer, non ricaricare il server certificate.
- Phone security profile names non inseriti sull’Expressway-C → registrazione endpoint in secure mode fallisce mentre quella non-secure funziona: la SAN corretta è il nome del security profile in formato FQDN.