Autor Thema: Eigene Root CA in Domino / com.ibm.jsse2.util.h: End user tried to act as a CA  (Gelesen 4103 mal)

Offline Gutierrez

  • Aktives Mitglied
  • ***
  • Beiträge: 112
Moin liebe Gemeinde,

wir haben hier Server, von denen ich Daten über HTTPS abgreifen möchte. Dazu benutze ich einen Java-Agent. Das läuft auch alles wunderbar über HTTP. Nur wenn ich HTTPS benutze, dann kommt die Meldung "No trusted certificate found" - soweit noch logisch, da wir nen eigenes internes Root-CA-Zertifikat haben. Also nach Anleitung [1] das Zertifikat mittels ikeyman in die Datei cacert installiert. Jetzt kommt die Fehlermeldung "End user tried to act as a CA".

Dann habe ich meine Eclipse IDE und die Oracle JVM bemüht, dort auch das Root-CA-Zertifikat installiert ---> funktioniert. Nochmal zum Gegencheck die JVM in Eclipse auf die Notes-Client-JVM umgestellt, mit dem gleichen ("Sample"-)Code ---> "End user tried to act as a CA".

Hat jemand eine Idee? :)

[1] http://www-01.ibm.com/support/docview.wss?uid=swg21588966

Beste Grüße
Gutierrez

Offline eknori

  • @Notes Preisträger
  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 11.710
  • Geschlecht: Männlich
Root CA certificate does not contain BASIC CONSTRAINTS extension.

Potential workaround is to use the IbmPKIX trustmanager instead of IbmX509 trustmanager at the client end. The trustmanager is set in java.security file using the property "ssl.TrustManagerFactory.algorithm"
Egal wie tief man die Messlatte für den menschlichen Verstand auch ansetzt: jeden Tag kommt jemand und marschiert erhobenen Hauptes drunter her!

Offline Gutierrez

  • Aktives Mitglied
  • ***
  • Beiträge: 112
Moin Uli,

hatte ich schon probiert, ergibt komischerweise bei mir keinen Unterschied im Ergebnis :(

Beste Grüße
Gutierrez

//Edit:
Bzgl. Root CA:

https://de.wikipedia.org/wiki/X.509
Zitat
BasicConstraints: Transitivitätsvertrauen ist ohne diese Erweiterung unmöglich. BasicConstraints sind:

    CA: Gibt an, ob das Zertifikat zu einer Zertifizierungsstelle gehört. In einer Zertifikatskette muss jedes Zertifikat, außer dem der letzten Instanz (des Users/Servers), als CA markiert sein.
    PathLen: Gibt an, wie lang die Zertifikatskette maximal sein darf.

Wenn ich in den Zertifikatsspeicher schaue (cacert), dann sehe ich, dass alle CA = true und PathLen haben, auch mein eingefügtes Zertifikat.

Abgesehen davon: Es funktioniert ja im Oracle JRE :)
« Letzte Änderung: 23.03.18 - 09:20:04 von Gutierrez »

Offline Gutierrez

  • Aktives Mitglied
  • ***
  • Beiträge: 112
Moin zusammen,

ich habe inzwischen herausgefunden, was das Problem ist. Das Problem ist die Art und Weise, wie die Zertifizierungskette vom Server präsentiert wird.

Bei dem Server, wo es nicht funktioniert, nämlich so:
C:\openssl-1.1.1>openssl s_client -connect HOSTNAME:443
CONNECTED(000000EC)
depth=2 C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Root CA
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = COMMON NAME, emailAddress = mail@organisation.org
   i:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Sub CA
 1 s:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = COMMON NAME, emailAddress = mail@organisation.org
   i:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Sub CA
 2 s:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Sub CA
   i:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Root CA
 3 s:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Root CA
   i:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Root CA
---


Hier ein funktionierendes Beispiel:
C:\openssl-1.1.1>openssl s_client -connect HOSTNAME:443
CONNECTED(000000EC)
depth=2 C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Root CA
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = COMMON NAME, emailAddress = mail@organisation.org
   i:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Sub CA
 1 s:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Sub CA
   i:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Root CA
 2 s:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Root CA
   i:C = LAND, ST = STADT, O = ORGANISATION, OU = ORGANISATIONSEINHEIT, CN = Root CA
---



Komischerweise wird das Serverzertifikat zweimal gesendet. Dann meckert das IBM Java - wie gesagt, mit der Oracle JVM geht's auch mit dem oberen Beispiel. Warum das so ist, weiß ich noch nicht, evtl. ein Konfigurationsfehler auf dem Server.

Beste Grüße
Gutierrez

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz