Verschil tussen een Java Keystore en een Truststore

Java Top

Ik heb zojuist het nieuwe aangekondigd Leer de lente natuurlijk, gericht op de basisprincipes van Spring 5 en Spring Boot 2:

>> BEKIJK DE CURSUS

1. Overzicht

In dit korte artikel geven we een overzicht van de verschillen tussen een Java-keystore en een Java-truststore.

2. Concepten

In de meeste gevallen, we gebruiken een keystore en een truststore wanneer onze applicatie moet communiceren via SSL / TLS.

Meestal zijn dit met een wachtwoord beveiligde bestanden die op hetzelfde bestandssysteem staan ​​als onze actieve applicatie. Het standaardformaat dat voor deze bestanden wordt gebruikt, is JKS tot Java 8.

Sinds Java 9 het standaard keystore-formaat is PKCS12. Het grootste verschil tussen JKS en PKCS12 is dat JKS een specifiek Java-formaat is, terwijl PKCS12 een gestandaardiseerde en taalneutrale manier is om versleutelde privésleutels en certificaten op te slaan.

3. Java KeyStore

Een Java-sleutelarchief slaat persoonlijke sleutelvermeldingen, certificaten met openbare sleutels of alleen geheime sleutels op die we kunnen gebruiken voor verschillende cryptografische doeleinden. Het slaat elk op onder een alias om het opzoeken te vergemakkelijken.

Over het algemeen bevatten keystores sleutels die onze applicatie bezit en die we kunnen gebruiken om de integriteit van een bericht en de authenticiteit van de afzender te bewijzen, bijvoorbeeld door payloads te ondertekenen.

Meestal we gebruiken een keystore als we een server zijn en HTTPS willen gebruiken. Tijdens een SSL-handshake zoekt de server de privésleutel op uit de keystore en presenteert de bijbehorende openbare sleutel en het certificaat aan de client.

Dienovereenkomstig, als de cliënt zichzelf ook moet authenticeren - een situatie die wederzijdse authenticatie wordt genoemd - dan heeft de cliënt ook een keystore en presenteert hij ook zijn openbare sleutel en certificaat.

Er is geen standaard keystore, dus als we een gecodeerd kanaal willen gebruiken, moeten we instellen javax.net.ssl.keyStore en javax.net.ssl.keyStorePassword. Als ons keystore-formaat anders is dan de standaard, kunnen we javax.net.ssl.keyStoreType om het aan te passen.

Natuurlijk kunnen we deze sleutels ook gebruiken om aan andere behoeften te voldoen. Privésleutels kunnen gegevens ondertekenen of ontsleutelen, en openbare sleutels kunnen gegevens verifiëren of versleutelen. Geheime sleutels kunnen deze functies ook uitvoeren. Een keystore is een plek waar we deze sleutels kunnen bewaren.

We kunnen ook programmatisch communiceren met de keystore.

4. Java TrustStore

Een truststore is het tegenovergestelde - terwijl een keystore doorgaans certificaten vasthoudt die ons identificeren, bewaart een truststore certificaten die anderen identificeren.

In Java gebruiken we het om de derde partij te vertrouwen waarmee we gaan communiceren.

Neem ons eerdere voorbeeld. Als een client via HTTPS met een Java-gebaseerde server praat, zal de server de bijbehorende sleutel opzoeken in zijn keystore en de openbare sleutel en het certificaat aan de client presenteren.

Wij, de klant, zoeken vervolgens het bijbehorende certificaat op in onze truststore. Als het certificaat of de certificaatautoriteiten die door de externe server worden gepresenteerd niet in onze truststore staan, krijgen we een SSLHandshakeException en de verbinding zal niet succesvol tot stand worden gebracht.

Java heeft een truststore gebundeld met de naam cacerts en het bevindt zich in de $ JAVA_HOME / jre / lib / security directory.

Het bevat standaard, vertrouwde certificeringsinstanties:

$ keytool -list -keystore cacerts Voer keystore-wachtwoord in: Keystore-type: JKS Keystore-provider: SUN Uw keystore bevat 92 items verisignclass2g2ca [jdk], 2018-06-13, trustCertEntry, Certificate fingerprint (SHA1): B3: EA: C4: 47 : 76: C9: C8: 1C: EA: F2: 9D: 95: B6: CC: A0: 08: 1B: 67: EC: 9D

We zien hier dat de truststore 92 vertrouwde certificaatvermeldingen bevat en een van de vermeldingen is de verisignclass2gca binnenkomst. Dit betekent dat de JVM automatisch certificaten vertrouwt die zijn ondertekend door verisignclass2g2ca.

Hier, we kunnen de standaard truststore-locatie overschrijven via het javax.net.ssl.trustStore eigendom. Evenzo kunnen we instellen javax.net.ssl.trustStorePassword en javax.net.ssl.trustStoreType om het wachtwoord en het type van de truststore op te geven.

5. Conclusie

In deze zelfstudie hebben we de belangrijkste verschillen tussen de Java-keystore en de Java-truststore en het doel ervan besproken.

We hebben ook laten zien hoe de standaardinstellingen kunnen worden overschreven met systeemeigenschappen.

Vervolgens kunnen we de volgende SSL-gids of de JSSE Reference Guide bekijken voor meer informatie over gecodeerde communicatie in Java.

Java onderkant

Ik heb zojuist het nieuwe aangekondigd Leer de lente natuurlijk, gericht op de basisprincipes van Spring 5 en Spring Boot 2:

>> BEKIJK DE CURSUS

$config[zx-auto] not found$config[zx-overlay] not found