Come è valido questo certitra di Java Keystore?

Question

Come è valido questo certitra di Java Keystore?

#1 da (3 voti)

3

Gestisco una vecchia app Java che distribuisce a Tomcat e che utilizza SSL (e quindi un keystore). È importante notare che questa app non potrebbe essere avviata anche se il certificato SSL è scaduto / scaduto / non valido!

Ogni anno il certificato SSL scade e quindi qualcuno deve sostituire il vecchio certificato in scadenza nel JKS con uno nuovo (fornito dall'IT). Ora sto iniziando questo processo / divertimento per quest'anno.

Ho iniziato eseguendo il comando keytool che stampa il contenuto di JKS:

keytool -list -v -keystore myapp.jks

A meno che non legga l'output errato, vedo solo un certificato scaduto nel 2015! Se è così, come diavolo questa app è stata lanciata per l'ultimo anno?!? L'unica cosa che io faccio vedere è un cert nella "catena" che scade nel 2034. Suppongo di non capire le catene SSL come dovrei, ma la mia teoria è che (in qualche modo) il il certificato che scade nel 2034 mantiene in qualche modo il mio certificato principale vivo / valido - è possibile ? Ecco un censurato / riassunto dell'output di quel comando di lista dall'alto:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: blah
Creation date: May 1, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
Owner: blah
Issuer: blah
Serial number: blah
Valid from: Thu Feb 16 15:49:19 EST 2012 until: Mon Feb 16 15:49:19 EST 2015
Certificate fingerprints:
    MD5:  blah
    SHA1: blah
    SHA256: blah
    Signature algorithm name: SHA1withRSA
    Version: 3

Extensions: 

#1: ObjectId: blah Criticality=false
AuthorityInfoAccess [

...a lot of stuff omitted for brevity

Certificate[3]:
Owner: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Issuer: OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
Serial number: 0
Valid from: Tue Jun 29 13:06:20 EDT 2004 until: Thu Jun 29 13:06:20 EDT 2034
Certificate fingerprints:
    MD5:  blah
    SHA1: blah
    SHA256: blah
    Signature algorithm name: SHA1withRSA
    Version: 3

...a lot more stuff, again omitted for brevity

Qualcuno può vedere una ragione per cui questo certificato sarebbe ancora valido?!?

java ssl

posta smeeb 27.01.2016 - 15:57

fonte

1 risposta

Leggi altre domande sui tag java ssl

In che modo il rendering di un documento Word è diverso dal rendering di un sito Web? [chiuso] Il ramo master non è un surrogato del tagging nel modello gitflow?

score 3 · Accepted Answer

Nel concatenamento di certificati, si consente essenzialmente all'emittente di certificati di convalidare i certificati per conto dell'utente. Il certificato GoDaddy in questa istanza è l'autorità di certificazione principale e convalida l'identità della CA principale. Inoltre ti rilasciano un certificato intermedio per rappresentare anche la tua organizzazione e questo è solo un altro certificato sulla catena.

Se in qualsiasi momento lungo la strada se il tuo certificato è compromesso, possono interrompere la convalida del tuo certificato di intermediario e ciò invalida tutti gli altri certificati di dominio rilasciati da GoDaddy. Perché stanno facendo questo? È così che un cliente, se lo desidera, può chiedere a GoDaddy come CA se l'identità del server è legittima. Il certificato CA radice identifica GoDaddy e si sa che è già affidabile e quindi la CA radice fornirà al cliente un pollice in su o un pollice in basso. La maggior parte dei browser ha questa funzione di convalida integrata. Si nota che nel browser in cui è presentato il certificato per un sito sicuro appare in verde. Ciò significa in genere che il browser ha convalidato il certificato presentato contro la CA ed è stato ritenuto valido. Quando un certificato scade in questa catena, la fiducia non può essere stabilita con il server dal client.

Quindi cosa succede in Java? Beh, un file JKS non è essenzialmente solo un keystore, ma anche un trust store per un'applicazione Java. Un trust store è qualcosa che un client Java utilizzerà per convalidare l'identità dei server attendibili a cui è consentito parlare. Generalmente su una tipica applicazione Java in esecuzione in una JVM tipica, non stabilirà una connessione SSL con una risorsa di rete sicura a meno che il certificato presentato non esista nel suo truststore. Tieni presente che questo certificato potrebbe non essere nemmeno tecnicamente valido oppure può essere autofirmato e non convalidato da una CA radice, ma se esiste sul Truststore specificato che è stato caricato nell'applicazione Java, continuerà a esserne fidato.

Ciò che non hai descritto è se questo certificato è per una risorsa di rete che fornisce come server o risorsa di rete che richiede come client. In quest'ultimo caso, potresti ricevere un avviso sul certificato scaduto, ma funzionerà comunque perché si trova nel tuo archivio fidato.