Selbst-signierte Zertifikate, Java, Hudson und JIRA

Ich versuche zum einrichten des JIRA-Hudson-plugin. Unsere JIRA-server ist gesichert mit einem selbstsignierten SSL-Zertifikat. Ich habe eingefügt, das Zertifikat für meine web-browser gespeichert hat, mit dem keytool-Befehl ein, und bekommen von Hudson, um es zu finden. Aber jetzt beschwert sich:

java.security.cert.CertificateException: No subject alternative names present

Den common name des Zertifikats ist "Unbekannt", und ich sehe nicht ein subject alternative names im Zertifikat

$ openssl x509 -in Unknown -text -noout
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 1214507595 (0x4863ea4b)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=US, ST=NJ, L=[Our town], O=[Our company], OU=[Our project], CN=Unknown
        Validity
            Not Before: Jun 26 19:13:15 2008 GMT
            Not After : May  5 19:13:15 2018 GMT
        Subject: C=US, ST=NJ, L=[Our town], O=[Our company], OU=[Our project], CN=Unknown
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                [omitted]
    Signature Algorithm: md5WithRSAEncryption
        [omitted]

(Identifizierung info redigiert und notiert Sie in Klammern.)

Gibt es eine Möglichkeit zur Befestigung einer alternativer Antragstellername für das Zertifikat? Oder gibt es eine andere Möglichkeit? Oder bin ich gezwungen zu hacken die Jira-Hudson-plugin?

InformationsquelleAutor der Frage AFoglia | 2010-09-01

  1. 23

    Den hostname verwendet, um den Zugriff auf Ihre Jira-server (z.B. jira.acme.com in https://jira.acme.com/) muss entweder mit einem von der CN Feldern für den Antragstellernamen oder, wenn es nicht funktioniert, eine der Subject Alternative Name des cert.

    Dies ist ausführlich in der RFC 2818:

    In einigen Fällen, die URI angegeben ist
    als eine IP-Adresse anstelle eines
    hostname. In diesem Fall wird die IP-Adresse
    subjectAltName vorhanden sein müssen, die
    Zertifikat und muss exakt mit der
    IP-Adresse in der URI.

    In Ihrem Fall ist Java beschwert, weil weder die CN ("Unbekannt"), noch eine Subject Alternative Name (da Sie keine haben) haben entsprechen den Hostnamen des Jira-Servers.

    Also, entweder generieren Sie ein Zertifikat mit der entsprechenden CNzum Beispiel mit keytool:

    Erstellen Sie ein Schlüsselpaar und das selbst unterzeichnete Zertifikat

    $ keytool -genkey -alias jira_acme_com -keyalg RSA -keysize 2048 -validity 365 -keystore jira_acme_com.jks 
Enter keystore password: 
Re-enter new password: 
Was ist dein vor-und Nachname? 
[Unknown]: jira.acme.com 
Wie lautet der name Ihrer organisatorischen Einheit? 
[Unknown]: Unser Projekt 
Was ist der name Ihrer Organisation? 
[Unknown]: Unsere Firma 
Was ist der name Ihrer Stadt oder Ort? 
[Unknown]: Unsere Stadt 
Was ist der name von Ihrem Staat oder Provinz? 
[Unknown]: NJ 
Was ist die zwei-Buchstaben-Länder-code für dieses Gerät? 
[Unknown]: UNS 
Ist CN=jira.acme.com, OU=Unser Projekt, O=Unsere Firma, L=Unsere Stadt, ST=NJ, C=de richtig? 
[Nein]: y 

Enter key password for 
(RETURN, wenn identisch mit keystore-Kennwort):

    Zu, um die persönlichen Daten

    $ keytool -list -v -keystore jira_acme_com.jks 
Enter keystore password: 

Keystore-Typ: JKS 
Keystore-provider: SUN 

Ihr keystore enthält 1 Eintrag 

Alias-Namen: jira_acme_com 
Creation date: Sep 4, 2010 
Eintrag Typ: PrivateKeyEntry 
Certificate chain length: 1 
Zertifikat[1]: 
Besitzer: CN=jira.acme.com, OU=Unser Projekt, O=Unsere Firma, L=Unsere Stadt, ST=NJ, C=US 
Emittent: CN=jira.acme.com, OU=Unser Projekt, O=Unsere Firma, L=Unsere Stadt, ST=NJ, C=US 
Seriennummer: 4c81e9a9 
Gültig ab: Sa Sep 04 10:39:37 CEST 2010 bis: Sun Sep 04 10:39:37 CEST 2011 
Zertifikat-fingerprints: 
MD5: 15:6A:E3:14:E2:78:F4:95:41:E6:33:C9:F8:8B:64:23 
SHA1: CD:A6:9A:84:18:E8:62:50:2C:DC:2F:89:22:F6:BA:E9:1A:63:F6:C6 
Signatur-Algorithmus-name: SHA1withRSA 
Version: 3

    Und setup Tomcat die Verwendung der Schlüsselspeicher.

    Wenn Sie möchten, erstellen Sie einen multihomed-Zertifikat haben, müssen Sie OpenSSL (keytool hinzufügen kann X509-extensions wie Subject Alternative Name). Diese links sind ausgezeichnete Ressourcen:

    Update: Gegeben, dass Sie nicht ändern können das Zertifikat (sollte man das wirklich haben erwähnt, dass), eine vorübergehende Lösung könnte sein, die änderung der lokalen /etc/hosts - Datei mit den erforderlichen Maschinen zu beheben Unknown der echten IP der Maschine. 

    123.123.123.123    Unknown

    So, dass Sie Zugriff auf https://Unknown/ von diesen Maschinen. Aber natürlich, das ist eher ein dirty-hack als eine echte Lösung und nicht skaliert.

    Kontaktaufnahme mit den admins zu bekommen, eine echte "gute" Zertifikat ist noch die wirklich gute Lösung.

    Ressourcen

    Referenzen

    InformationsquelleAutor der Antwort Pascal Thivent

  2. 1

    Wenn ich mich nicht Irre, SSL erfordert, dass der common name des Zertifikats enthalten den Hostnamen, den Sie versuchen zu verbinden, dass auf diese Weise der client-Seite können Sie überprüfen, ob das Zertifikat ist nicht nur vertraut im Allgemeinen, aber für Vertrauenswürdige der Lage.

    Ich bin davon ausgegangen, dass Sie die Erzeugung des Zertifikats mit OpenSSL. Gibt es einen Grund, warum man die Einstellung nicht cn=[yourserver]?

    Kann es sein, dass, wenn Sie nicht finden können, den richtigen hostname in dem gemeinsamen Namen,, dass das plug-in versucht, um es zu suchen in einem subject alt name, und wenn das fehlschlägt, weil es keine subjectAltName, Sie sind immer eine schlechte Fehlermeldung.

    Sowieso, wenn Sie dieses für mehrere Standorte, müssen Sie den Hostnamen in die subjectAltName. Ich habe eine Seite gefunden, die beschreibt, wie erstellen Sie Ihre self-signed cert richtig.

    http://library.linode.com/ssl-guides/subject-alt-name-ssl

    Hoffe, das hilft.

    InformationsquelleAutor der Antwort Shawn D.

  3. 0

    Gibt es mehrere mögliche Lösungen, jeder mit seinen eigenen Schmerzen.

    • Erzeugen Sie ein neues Zertifikat für JIRA, dieses mal die Angabe einer CN bei der Generierung des geheimen Schlüsselpaar für das Zertifikat.

      Kann ich nicht sehen, warum ein neues Zertifikat generiert werden kann; ich bin mir ziemlich sicher, dass die anderen client an den JIRA-server sind auch auf einige Probleme, vor allem Warnungen von Browsern, für die beschriebene Zertifikat. Alle Kunden (und client-Anwendungen) müssen daher neu geprüft werden, aber dies ist nicht ein Schmerz, wenn das selbstsignierte Zertifikat ausgestellt wurde, durch eine lokale ZERTIFIZIERUNGSSTELLE, die das Vertrauen aller Kunden.

    • Bearbeiten Sie die DNS-Einträge, um sicherzustellen, dass die lookup 'Unbekannt' aus dem Hudson-server, Punkte für den server, auf dem JIRA installiert ist [ich habe jemand erinnern, dass es Schmerzen verbunden mit einigen Lösungen, die 🙂 ]. Dadurch wird sichergestellt, dass der Wert der CN im Zertifikat gespeichert übereinstimmungen mit der hostname - Sie benötigen, um zu konfigurieren Hudson benutzen Sie eine URL wie http://Unknown/..... Und oh, verwenden Sie diese nur, wenn Sie in einer wirklich engen Stelle; Sie wollen nicht zu sein zu erklären, warum Sie dies Tat.

    InformationsquelleAutor der Antwort Vineet Reynolds

Schreibe einen Kommentar