User Tools

Site Tools


certstuff
Smartcards
Zerts

Pastes

Quirk of update-ca-certificates on one system

Running update-ca-certifcates on a ubuntu 18 system resulted an total clear out of all symlinks in /etc/ssl/certs.

As openssl does not look into the file /etc/ssl/certs/ca-certificates.crt but into everly symlinked file in /etc/ssl/certs it fails to verify all ssl certs.

For some reason this line in /usr/sbin/update-ca-certificates

  find $ETCCERTSDIR -type l ! -exec test -e {} \; -print | while read orphan

does not work on that system. It thinks every file is a broken symlink..

I had change it to this line (this kind of symlink check is recommend on stackexchanged,com

  find $ETCCERTSDIR -xtype l | while read orphan

Client Certificates

Good complete overview of different crypt storage formats

What contents do pfx, pem extension files support and what is their usage/background https://crypto.stackexchange.com/questions/43697/what-are-the-differences-between-pem-csr-key-crt-and-other-such-file-exte

Erklärung was bei mTLS zusätzlich zur normalen Browser TLS Handshake passiert
Gedächnisstütze zu Wahrheiten im Zusammenhang mit Java und des Zertifikatspeichern
  1. Die erste Erfahrungen mit Java und Cryptozertifikaten liessen mich glaub das Java im ein eigenens Format für Certifkatsspeicher hat das vom Linux und/oder Windows abweicht
  2. Richtig ist weiterhin das Java bzw. JVMs die java byte-code ausführen unter Linux und Windows eine eigene Zertifikatsspeicher führen immer synchron mit dem des Betriebssystem gepflegt werden sollte
  3. Ich habe aber auch gedacht das Format dieser Speicher ebenfalls nur Java-eigen ist und nicht verwandt oder kompatibel mit andere Format wie pem oder pkcs12
  4. Das war mal richtig ist aber mitterweile nicht immer so
  5. Früher hiess .jks auch immer JKS format. Mittlerweile unterstützt Java aber auch PKCS12 Container, wie diese Quelle von IBM sagt: https://www.ibm.com/docs/en/was-liberty/nd?topic=liberty-default-keystore-type-changed-pk
  6. Die obige Quelle reden immer über das IBM Java Produkt Liberty-Produkt aber diese Quelle unterstüzt das für Java gesagt für gesamt Java gilt: https://bugs.openjdk.org/browse/JDK-8178828

Zitat:

As of JDK 9, the default keystore type (format) is “pkcs12” which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was “jks” which is a proprietary format. Other keystore formats are available, such as “jceks” which is an alternate proprietary keystore format with stronger encryption than “jks” and “pkcs11”, which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards.

Das obige gilt also ab JDK 9 (für openjdk jedenfalls, ich vermute auch für alle Java implementierungen Achtung: das obige gilt erstmal nur für den Keystore und nicht unbedingt für den Truststore, was mir aber erstmal egal ist, denn ich brauche für meinen Anwendungsfall (Client Zertifkat Autentifierung evntl. gleich mTLS?).

Was ich jetzt klären möchte: Also wenn ich mit ein Javaprogramm starte und die JVM mit -Dkeystorebla parametern versehe.

- Kann ich direkt eine ein pkcs12 Datei nehmen, die direkt von openssl erzeugt wurde oder muss das irgendwie doch durch das java keytool durch - Ich hatte ein komisches Verhalten gesehen, das java mit dem keystore immer auch auf den truststore zugeriffen hat…wie hatte ich das problem eigentlich gelöst - Macht es sinn das mit curl zu testen? kann ich das local mit einem docker ngins testen?

certstuff.txt · Last modified: 2023/03/31 11:45 by rklein