Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 38 subscribers
  • Views 2883 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL Issues: I broke the webinterface

newone

Hallo zusammen!

Mir sind heute (mal wieder) die Zertifikate abgelaufen. (Signing CA & Webinterface)
Daher habe ich heute beides neu generiert und anschliessend importiert. Beide Zertifikate habe ich von meiner privaten CA unterschrieben bzw. ausgestellt.
Ich habe aber vermutlich IRGENDEINEN Fehler gemacht beim Webinterface Zertifikat. :(

Um das Cert für das webinterface zu generieren habe ich folgendes getan:

  1. Auf meinem Client mit openssl einen privaten Key erzeugt und anschliessend ein CSR erstellt:
    "openssl req -config openssl.cnf -new -newkey rsa:4096 -keyout privkey.pem -out utm.csr"
  2. Den CSR habe ich anschliessend über das Webinterface meiner CA eingekippt und das unterschriebene Cert heruntergeladen (Base-64)
  3. Das unterschriebene Zertifikat mit openssl, zusammen mit dem privkey, in ein PKCS12 gegossen:
    "openssl pkcs12 -export -in signed_key_base64.cer -inkey privkey.pem -out utm_2018.p12"
  4. Das Zertifikat über das webinterface hochgeladen und "aktiv" gesetzt.

Dies hat dazu geführt das ich jetzt im Firefox einen: "SEC_ERROR_INADEQUATE_CERT_TYPE" bekomme und nicht mehr auf das Webinterface zugreifen kann.:(
Ich habe diesen Vorgang in der Vergangenheit schon ein paar mal so gemacht und in meinem privaten Wiki genau so dokumentiert. (letzter Cert renew war 2016)
IRGENDWAS scheint sich geändert zu haben das das so nicht mehr funktioniert :(

Im Moment weiss ich leider nicht was ich machen kann um wieder an das Webinterface zu kommen. EGAL was ich mit Firefox anstelle, er weigert sich eine Verbindung aufzubauen.
Das Firefox hier "strikt" ist ist mir bekannt, ich habe auch schon IE oder Opera ausprobiert mit der Hoffnung einen "Mir egal, ignorier den Cert-Error"-Knopf zu bekommen: Fehlanzeige.

Jetzt meine Fragen:

  • Gibt es eine Möglichkeit das für das Webinterface aktive Zertifikat über die Shell zu ändern? (Das alte, zwar abgelaufene, Zertifikat ist noch im Zertifikatspeicher.)
  • Mir ist leider gerade vollkommen unklar was das Problem mit dem erstellten & signierten Zertifikat überhaupt ist.

Ich habe das Zertifikat zum "Spass" mal auf meinem Client installiert und betrachtet: Ich habe über SAN weitere DNS-Namen mit in das Zertifikat aufgenommen, die Fehlen diesmal. (Im alten sind sie drin!) Ich vermute irgendwas hat mit meiner openssl config nicht funktioniert. Aber, eins nach dem anderen: erstmal wieder Zugriff bekommen.

Hat jemand eine Idee für mich? Da wäre ich wirklich sehr dankbar :)

LG



This thread was automatically locked due to age.
Parents
  • +1

    Solved!

    Ich habe den Fehler in meinem Vorgang gefunden:

    Ich habe die falsche Zertifikatsvorlage beim signieren des csr in der CA ausgewählt. Dadurch wurde ein User-Zertifikat daraus was so halt einfach nicht fährt. :)
    Ich habe die UTM von einem Backup wiederhergestellt und dann einfach beide Zertifikate neu installiert. (Sub-CA und Webinterface)

    So ist wieder alles "grün", es gibt keine Zertifikatswarnungen mehr. Was ich mir bei dem Gefrickel so gedacht hab:
    Warum wird beim Webinterface Zertifikat neu erstellen (management -> webadmin -> https certificate -> Re-generate WebAdmin Certificate) eigentlich nicht die "Signing ca" verwendet? Wenn man den Vorgang durchführt wird ein self signed zertifikat erstellt. ?! Verstehe hier den Sinn nicht. ( IF SIGNING-CA=PRESENT THEN USE SIGNING-CA?)

    Ich habe stattdessen auch mal versucht einfach ein neues Zertifikat zu erstellen (remote access -> certificate Management), was anständig signiert wird, aber da habe ich nicht die Möglichkeit SAN (Subject Alternative Names) einzugeben.
    Ich verwende da SANs da das Host-Zertifikat für das Client-Portal und für das Webinterface verwendet wird: Zugriff auf das Webinterface läuft über den internen hostnamen, Zugriff auf das Client-Portal über den externen sowie internen hostnamen.

    So wie es jetzt ist brauch der Client nur der Haupt-CA zu vertrauen und alles was darunter abläuft ist "trusted".

Reply
  • +1

    Solved!

    Ich habe den Fehler in meinem Vorgang gefunden:

    Ich habe die falsche Zertifikatsvorlage beim signieren des csr in der CA ausgewählt. Dadurch wurde ein User-Zertifikat daraus was so halt einfach nicht fährt. :)
    Ich habe die UTM von einem Backup wiederhergestellt und dann einfach beide Zertifikate neu installiert. (Sub-CA und Webinterface)

    So ist wieder alles "grün", es gibt keine Zertifikatswarnungen mehr. Was ich mir bei dem Gefrickel so gedacht hab:
    Warum wird beim Webinterface Zertifikat neu erstellen (management -> webadmin -> https certificate -> Re-generate WebAdmin Certificate) eigentlich nicht die "Signing ca" verwendet? Wenn man den Vorgang durchführt wird ein self signed zertifikat erstellt. ?! Verstehe hier den Sinn nicht. ( IF SIGNING-CA=PRESENT THEN USE SIGNING-CA?)

    Ich habe stattdessen auch mal versucht einfach ein neues Zertifikat zu erstellen (remote access -> certificate Management), was anständig signiert wird, aber da habe ich nicht die Möglichkeit SAN (Subject Alternative Names) einzugeben.
    Ich verwende da SANs da das Host-Zertifikat für das Client-Portal und für das Webinterface verwendet wird: Zugriff auf das Webinterface läuft über den internen hostnamen, Zugriff auf das Client-Portal über den externen sowie internen hostnamen.

    So wie es jetzt ist brauch der Client nur der Haupt-CA zu vertrauen und alles was darunter abläuft ist "trusted".

Children
No Data
Unfiltered HTML