www.zeroshell.net

[NdK]

Ero indeciso tra bug e nuova funzionalità, ma propendo per il bug...

In pratica, se ZS non è la CA principale (raccomandato: non è bello avere la CA sul firewall!), non si riesce a dirgli di passare la certificate chain almeno per l'autenticazione web.

Nel mio caso ho una root CA, il cui certificato viene caricato dai client in modo sicuro (lo consegno a mano). Questa root ha firmato i certificati per altre CA (server ed utenti) ed infine la ca dei server ha firmato il certificato di ZS.
Ma ora gli utenti si trovano a dover aggiungere anche la ca server per non ricevere un avviso, e questo è pericoloso...

Io il certificato l'ho caricato completo di tutta la sua catena, ma a quanto pare è stata strippata, e questo mi ha fatto propendere per il bug.

[NdK]

Piccola correzione.
Per quanto riguarda il captive portal, la certificate chain viene esportata ma solo se:

1. si importano come CA affidabili tutte quelle necessarie per la catena
   
2. le si abilita
   
3. si abilita l'autenticazione x509 del CP
   
4. si salvano le impostazioni
   

A questo punto è possibile disabilitare l'autenticazione x509 del CP che la catena dei certificati rimarrà caricata comunque.

Chi usa certificati "normali" (firmati da una CA riconosciuta), però, è bene che tenga l'autenticazione x509 disattivata, o potrebbero venire riconosciuti come validi anche certificati rilasciati da una delle CA intermedie...
Per evitarlo (e quindi disaccoppiare l'autenticazione degli utenti dalla certificazione del server), andrebbe usata la direttiva SSLCertificateChainFile, ma questo richiederebbe anche il supporto da parte del resto dell'interfaccia (nel momento in cui si carica il certificato per il server non dovrebbe venire mantenuto il solo certificato principale ma tutta la catena).
In alternativa, si può usare la semplice concatenazione di tutte le 'trusted CAs' caricate già presente. Una patch a /root/kerbynet.cgi/template/cp_as-httpd.* potrebbe essere semplicemente l'aggiunta della riga centrale: