"Die Signatur stimmt nicht überein" Fehler beim Import eines Zertifikats in den Keystore - warum?

Question

Grundsätzlich handelt es sich hier um ein Keytool-Problem und hat nichts mit Shibboleth zu tun, aber es wäre wahrscheinlich hilfreich zu verstehen, was ich erreichen möchte (Überspringe die Teile in fett, wenn die Shibboleth-Sachen für dich nichts bedeuten):

Ich versuche, eine Shibboleth-Single-Sign-On-Konfiguration einzurichten. Der IdP wurde bereits eingerichtet und ich habe einen SP eingerichtet, der damit kommuniziert. Bis jetzt (nach viel Herumprobieren) funktioniert alles gut - der SP (der in einen Apache-Reverse-Proxy eingebunden ist) fängt Anfragen an gesicherte Ressourcen ab und leitet sie korrekt an den IdP weiter, der eine Anmeldeseite anzeigt. Nach dem Anmelden antwortet der IdP und übergibt dem SP ein Token.

Der SP sollte dann den IdP kontaktieren, um das Token in Attribute umzuwandeln, die für die angemeldete Person gültig sind. Hier beschwert sich der IdP jedoch darüber, dass die Nachricht nicht den Sicherheitsanforderungen entspricht.

Wie mir scheint, akzeptiert tomcat das Zertifikat des SP, das selbst signiert wurde, nicht.

Stattdessen versuche ich ein CA-Zertifikat zu generieren und damit das Zertifikat zu signieren. Ich habe das CA-Zertifikat in $JAVA_HOME/jre/lib/security/cacerts hinzugefügt, damit keytool es vertrauen sollte, aber wenn ich versuche, das signierte SP-Zertifikat in den Keystore zu importieren, erhalte ich den Fehler:

keytool error: java.security.SignatureException: Signatur stimmt nicht überein.

Der Importbefehl, den ich verwende, lautet:

keytool -import -v -alias sp_signed_cert -keystore idp.jks -trustcacerts -file server.crt

wo server.crt das signierte SP-Zertifikat ist.

Warum erhalte ich diesen Fehler und was kann ich dagegen tun?

Die einzigen Optionen, die mir bleiben, sind:

• Apache vor dem Tomcat einzusetzen, auf dem der IdP läuft, und seine Einstellung "optional_no_ca" zu verwenden, um ein selbst signiertes Zertifikat verwenden zu können,
• für ein bekanntes CA zu bezahlen, um das Zertifikat zu signieren (was für ein Proof-of-Concept nicht wirklich geeignet ist),

Answer 1

Nun ja, ich kenne mich ehrlich gesagt nicht mit SSO oder IdP aus, aber hier ist mein Versuch:

Es scheint mir, dass Tomcat das Zertifikat des SP nicht akzeptiert, da es selbst signiert wurde.

Wenn das tatsächlich das Problem ist, müssen Sie nur dieses Zertifikat in den Truststore von Tomcat importieren.

Stattdessen versuche ich, ein CA-Zertifikat zu generieren und dieses zum Signieren des Zertifikats zu verwenden.

Ich habe keine Ahnung, was du hier versuchst zu machen. Von wem wurde es signiert?
Das cacerts enthält standardmäßig das Zertifikat aller vertrauenswürdigen CAs, z.B. Verisign.
Außerdem versucht der Importbefehl, den du in deinem Beitrag erwähnst, in idp.jks zu importieren und nicht in cacerts

Answer 2

Setzen Sie Apache vor den laufenden IdP-Tomcat und verwenden Sie dessen "optional_no_ca"-Einstellung, um ein selbstsigniertes Zertifikat verwenden zu können,

Sie brauchen keinen Apache vor Tomcat, außerdem sagen die Shibboleth-Leute nein.

Bezahlen Sie eine bekannte CA, um das Zertifikat zu signieren (für einen Proof-of-Concept nicht wirklich angemessen)

Der Bedarf an einer bekannten CA besteht nur wegen der Vertrauensketten, Sie müssen nie bezahlen, wenn Sie nicht möchten.

Versuchen Sie zunächst ohne Verschlüsselung zu kommunizieren, da es sich um einen Proof-of-Concept handelt.

Der Fehler tritt auf, wenn Sie den Import durchführen? Warum importieren Sie nicht das CA-Zertifikat anstelle eines bestimmten SP?