Quali dati dovrei convalidare durante la convalida dei certificati X.509 usando Java?

Senza la revoca del certificato, l'unico modo per convalidare un certificato è assicurarsi che le date siano buone e che la CA che ha firmato sia attendibile. Cosa succede se si è emesso un certificato client per un utente per l'accesso VPN e tale certificato è stato smarrito o rubato? Cosa succede se un server è stato compromesso e il certificato non è più affidabile? La revoca del certificato consente di "revocare" singoli certificati che non dovrebbero più essere accettati. Durante la convalida di un certificato, il client controllerà l'elenco revoche di certificati (CRL) per un elenco di certificati che sono stati revocati per garantire che il certificato sia ancora valido.

La convalida del certificato è, huh, un po 'più che guardare le date.

Dai un'occhiata a RFC 5280 . Sarebbe del tutto illusorio credere che si possa implementare la convalida dei certificati con qualsiasi tipo di sicurezza e interoperabilità decente, se non si legge più volte e si capisce perfettamente quel documento. Un sacco di crude si è accumulato sugli standard relativi a X.509, il che rende un'implementazione scoraggiante l'implementazione della convalida dei certificati. La guida di stile X.509 è una lettura obbligata (anche se ora è un po 'datata , dà comunque la giusta impressione sullo stato delle cose nel mondo X.509).

In realtà, se il tuo capo ti ha detto di implementare la convalida X.509, allora o ti ha preso in giro, o è seriamente disconnesso dalla realtà.

La soluzione migliore è utilizzare una libreria esistente che già fa il lavoro. Fortunatamente, Java stesso viene fornito con un codice per questo; cercalo nel pacchetto java.security.cert . Leggi la Guida del programmatore Java PKI e l'adiacente nota .

Revoca è l'equivalente PKI di "Whoops, sorry, ignorare il mio messaggio precedente". Viene usato per dichiarare che un dato certificato non deve essere usato, anche se tutto l'armamentario delle firme e dei vincoli del nome e degli alberi delle politiche e degli usi chiave dice che tutto va bene con esso. Il controllo dello stato di revoca comporta il download di elenchi di revoca potenzialmente enormi (CRL) e / o la comunicazione con server online che affermano lo stato di alcuni certificati (OCSP); in entrambi i casi, è costoso, ingombrante e funzionerà solo nella misura in cui la corrispondente Autorità di certificazione pubblica le informazioni di revoca in modo corretto e conforme agli standard, ovvero non così spesso.

Oltre a ciò che @Tom Leek ha detto sull'API del percorso di certificazione, sembra che tu stia parlando di "certificati TLS", che presumo implichi che potresti utilizzare il tuo certificato X.509 nell'ambito di TLS.

Per fare ciò come parte dello stack TLS di Java (JSSE), puoi utilizzare l'infrastruttura X509TrustManager esistente. Devo ammettere che non sono sicuro che verifichi con RFC 5280 o RFC 3280 , la sua specifica precedente (probabilmente dipende dalla versione di Java che stai utilizzando). Sto assumendo Sun / Oracle JRE 6, ma l'implementazione varierà a seconda del provider di sicurezza installati. Questo è un wrapper in cima all'API del percorso di certificazione già menzionato.

Ecco un esempio che inizializza un TrustManagerFactory con null : utilizzerà valori predefiniti per gli ancoraggi attendibili . Quanto segue ti darà i gestori della fiducia:

TrustManagerFactory factory = TrustManagerFactory.getInstance("PKIX");
factory.init((KeyStore)null);
TrustManager[] trustManagers = factory.getTrustManagers();

I metodi check* del gestore di fiducia generano un CertificateException quando qualcosa è fallito. Controlla anche la validità della data.

I trust manager possono essere utilizzati per inizializzare un SSLContext , che può quindi essere utilizzato per inizializzare un SSLSocket (tramite la fabbrica) o SSLEngine . Per impostazione predefinita, SSLSocketFactory utilizza il SSLContext predefinito, inizializzato con un numero di valori predefiniti .

Puoi anche creare il tuo TrustManager se devi controllare ulteriori estensioni per la tua applicazione e / o rilassare determinate regole. (Ad esempio, ho scritto una piccola libreria per racchiudere gestori di fondi esistenti e accetta altre forme di certificati, come i certificati proxy ( RFC 3820 - non 3280).)

Per verificare estensioni specifiche, ti consigliamo di utilizzare BouncyCastle , poiché fornisce strutture di dati per gestire ASN.1 e così via.