Subversion Server SSL certificate verification failed: und der andere Grund(s)

Hatte ich ein SVN-system und funktioniert gut, und nach einem kürzlichen upgrade plötzlich aufgehört zu arbeiten. Mein setup:

  • Habe ich ein repository gehostet auf einem Windows 2008 server mit VisualSVN Server 2.7.4. Der server bietet mir die Möglichkeit der Generierung von selbst-signierten Zertifikaten wird, die Eingabe meiner eigenen hostname oder die anderen Daten, wie gewünscht.

  • Ich bin mit Eclipse (Kepler) für die java-Programmierung sowohl auf der gehosteten Maschine und mein eigenes MacBookPro mit Mac OS X 10.9.1 (Mavericks). Ich habe das subclipse-add-on zu Eclipse, die subversion erfordert, die mit java-HL.

  • Habe ich macports installiert und den neuesten subversion/javahl angeforderten Pakete von subclipse. Die Eclipse/subversion-interface scheint zu funktionieren gut, aber es gibt Kommandozeilen-subversion-Fehler, die Eclipse nicht mit der Navigation gut. Die Lösung der Befehlszeilen-Fehler ist die Hauptsache.

  • Ich hatte vorher den folgenden Versionen installiert via macports, und Dinge, die schien zu funktionieren gut:

    subversion @1.8.5_1+universal

    subversion-javahlbindings @1.8.5_0+no_bdb+universal

  • Als Teil der Installation/Fehlersuche etwas nichts zu tun haben, habe ich ein Upgrade alle meine macports, die installiert die folgenden neuen Versionen:

    subversion @1.8.8_0+universal

    subversion-javahlbindings @1.8.8_0+no_bdb+universal

  • Nach dem upgrade svn über eclipse auf meinem mac schlägt fehl. Ich kann erzwingen, dass es über die Kommandozeile, indem Sie vorübergehend die Annahme eines Zertifikats. Es funktioniert immer noch völlig problemlos auf dem Windows 2008 server Maschine.

Ersten mal nach einem Zertifikat zu ändern, bekomme ich die option zu akzeptieren, dauerhaft, aber nachdem Sie dies getan haben, schlägt fehl und fällt zurück auf einen zweiten "temporären" Dialog. 

$ svn update
Updating '.':
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate has an unknown error.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject or accept (t)emporarily? t
(credentials dialogue)
At revision 46.
  • Folgende, zukünftige versuche immer noch zu dem Fehler führen und Anforderung vorübergehend zu akzeptieren:
$ svn update
Updating '.':
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate hostname does not match.
 - The certificate has an unknown error.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject or accept (t)emporarily? t
At revision 46.

Mehrere web-Recherchen, einschließlich dieser Website und andere, haben darauf hingewiesen, dass die Authentifizierung von Dateien in ~/.subversion als potenziell das problem, aber alle vorgeschlagenen Lösungen (löschen, ändern von Eigentümer-und Zugriffsrechte, etc.) haben es versäumt, das problem zu lösen.

Spezifische Fragen:
1. Ich kann nicht herausfinden, wie Sie zum zurücksetzen der vorherigen subversion (1.8.5) in macports zu sehen, ob es war ein bug in der version 1.8.8 habe ich aktualisiert.
2. Vorausgesetzt es gibt keine Fehler in 1.8.8, gibt es etwas, was ich tun kann, um potenziell beheben Sie diese und lernen Sie meine Zertifikate dauerhaft akzeptiert?

BEARBEITEN:
- Ich habe in der Lage, um loszuwerden, der "hostname" - Fehler durch die Veränderung meiner selbst-signiertes Zertifikat Hostnamen in numerische IP. Aber auch alle anderen Symptome bleiben, einschließlich der geheimnisvollen "Das Zertifikat hat einen unbekannten Fehler."
- Ich bin davon überzeugt (wenn die Kommentare etwas anderes angeben), dass die 1.8.8 upgrade brach etwas auf Mac OS X und bin sehr daran interessiert, Rollback-Versionen zu beheben weiter. Aber ich nehme an, das ist eine neue Frage...

  • Ich war in der Lage, herauszufinden, wie man wiederherstellen von subversion-1.8.5 über diesen link: trac.macports.org/wiki/howto/InstallingOlderPort und die Rückkehr zum 1.8.5 ist das problem gelöst.
  • Und als einen letzten follow-up, anscheinend gab es einen Fehler mit subversion 1.8.8 und Leibeigener 1.3.2 und früher. Upgrade Leibeigener zu 1.3.4 das problem gelöst also ich bin jetzt auf die neueste version von subversion und Leibeigene.
InformationsquelleAutor Daniel Widdis | 2014-03-01
  1. 7

    Wie merkwürdig, hatte buchstäblich ein ähnliches Problem vor einem Tag. wie auch immer, ich kann falsch sein, aber die scheinbare Sicherheit für SVN auf 1.8.8 ist enger als die vorherigen Versionen. Was Zertifikate, die Sie gezwungen svn zu akzeptieren, kann nicht mehr "akzeptabel" durch die neuen standards. ich war falsch, aber das ist irrelevant.

    Wenn man sich die Fehler, die Sie-vorausgesetzt, Sie werden sehen:

    Zertifikat hostname stimmt nicht überein.

    Dies ist ein SSL-Fehler, der svn nicht ignorieren, es bedeutet, dass Sie eine Verbindung zu einem anderen hostname als dem, was Sie angegeben haben. Die Sache ist die, während https://192.168.100.59:443 beziehen sich auf die gleiche URL als repository-server an, zum Beispiel: https://foobar.com:443 der SSL-handshake wird scheitern, wie die Hostnamen Stimmen nicht überein.

    Dieses Problem bleibt für jeden Fall, in dem Sie Ihr repository-URL-hostname stimmt nicht überein, reagiert, indem Sie die SVN-server-Zertifikat.

    Ich implizieren Sie ein selbst-signiertes Zertifikat über das VisualSVN-certificate generation tool. Zu lösen, erstellen eines neuen Zertifikat und stellen Sie sicher, dass der hostname übereinstimmt, dass Ihre realen Hostnamen. Sollte das beheben Ihre Probleme.

    Bitte beachten Sie: Du bist immer noch gonna get das erste Dialogfeld mit der Warnung, dass Sie über ein Zertifikat, das ist nicht verifiziert/gültig, aber man sollte Sie nicht bekommen, den zweiten dialog. Auch, stellen Sie sicher, dass sowohl client-und server-SVN-Versionen sind die gleichen, unterschiedliche SVN-Versionen verursachen große Chaos.

    Edit:

    Sorry, ich lese den Fehler nach hinten, wird Ihr Zertifikat für den Hostnamen ist offenbar 571458-tools1 sein, wenn es 192.168.100.59 wenn Sie darauf zugreifen möchten. Folgen Sie dem gleichen Zertifikat regeneration der oben genannten Schritte, aber verwenden Sie den Hostnamen des 192.168.100.59 statt 571458-tools1.

    Bitte beachten Sie, dass dies dann erlauben SSL - /TLS-verbindungen nur bei Verwendung der internen IP direkt.

    • 1.8.8 nicht mehr der strengen Anforderungen für die Zertifikate. Sollte es keine änderung für diese für die Benutzer auf dem Mac 1.8.8. Windows wurde geändert, so dass Sie es verwenden könnte, das system wird eine Liste von vertrauenswürdigen root-Zertifikaten. OS X immer noch nicht verwenden Sie die Liste der vertrauenswürdigen Zertifikate in den Schlüsselbund, sondern die Liste der Vertrauenswürdige Zertifikate von openssl, die in der Regel nichts auf dem Mac. Das ist der Grund für die erste Eingabeaufforderung.
    • Okay, danke für die Informationen. Aber es ist ganz offensichtlich OP ist ein selbst-signiertes Zertifikat, ob ein mac nutzt seinen Schlüsselbund (oder war es keyring?) Zertifikate oder openssl ist, ist irrelevant. Die erste Eingabeaufforderung ist verursacht durch eine ganze Gruppe von Fehlern: nicht vertrauenswürdig, nicht übereinstimmende Domäne und einige Allgemeine "unbekannter Fehler".
    • CPU-Terminator, danke für den Rat, aber es scheint nicht zu helfen, weil ich Zugriff auf bin hinter einem vpn, so dass die numerische IP ist, die nur den Hostnamen, die ich für den Ziel-Rechner. Mit den voll-571458-tools1.mycompanyname.com URL gibt eine komplett andere IP. Ich habe versucht, die Unterzeichnung des Zertifikats mit der numerischen IP-Adresse nur, und es gibt keinen Unterschied in den Ergebnissen.
    • Sagen Sie, dass Sie Zugriff auf das repository mit der IP-literal in dem Zeugnis genannten? Da svn anscheinend denkt Sie nicht. Die ganze basis von SSL/TLS ist (relativ) schwer zu manipulieren. Wenn Ihr VPN ermöglicht anderen SSL/TLS-Datenverkehr durch zu gehen, ich kann mir nicht vorstellen, wie es wäre, ein Problem.
    • Terminator, ja, ich access direkt mit der IP. $ svn info Pfad: . Working Copy Root Path: /Users/danielwiddis/Documents/workspace/Aufstieg-JPPF URL: 192.168.100.59/svn/Ascent/Ascent-JPPF Relative URL: ^/Aufstieg-JPPF Repository Root: 192.168.100.59/svn/Ascent ich habe versucht, die Unterzeichnung des Zertifikats mithilfe der numerischen IP-Adresse als der hostname, no go.
    • Hast du versehentlich die port-Nummer oder https://? Der hostname darf nur die numerischen IP. Auch, nachdem Sie mit den numerischen IP direkt ein, funktioniert es immer noch zeigen The certificate hostname does not match.?
    • Ja, ich habe versucht, nur die IP. Ich habe auch versucht es mit der port-Nummer, und gerade über jede andere Variante die ich mir denken kann, wie eine Fehlersuche bemühen. (Zum Glück, VisualSVN Server macht das wechseln der Zertifikate eine triviale übung... wünschte nur, ich finden konnte die combo, die funktioniert!)
    • Habe gerade versucht es wieder.... $ svn update Updating '.': Error validating server certificate for '192.168.100.59:443': - Das Zertifikat hat einen unbekannten Fehler. Zertifikats - Informationen: - Hostname: 192.168.100.59 - Gültig: von Mär 1 02:21:16 2014 GMT bis zum Feb 27 02:21:16 2024 GMT - Emittenten: - Fingerabdruck: WERDEN:C4:65:B6:0E:BD:5C:EE:F4:DB:A9:E1:EB:AE:B6:BC:43:F2:E7:5E (R)werfen oder akzeptieren (t)emporarily? t revision 46.
    • lassen Sie uns weiterhin diese Diskussion im chat
    • Zum schließen der Schleife, chat-Diskussion bestätigt, dass die änderung der Hostnamen aufgelöst, die Fehler, sondern die "unbekannten Fehler" bleibt. Frage ist noch offen.
    • FYI Subversion Festungs-HTTP-Bibliothek unterstützt nicht unterstützt überprüfen von Zertifikaten mit ips in Ihnen. Neon hat (war der Standard bis zu 1.7.x und ist gar nicht mehr enthalten in 1.8.x). Ich glaube nicht, dass ist hier das Problem, aber erwähnenswert.
    • Ben, vielen Dank für die Kommentare. Ich sehe, Sie sind ein Mitglied des subversion-Entwicklerteams. Ich war in der Lage, wieder auf 1.8.5 und das problem ging Weg. Lassen Sie mich wissen, wenn es einen Weg gibt, mit Ihnen zu arbeiten, um festzustellen, was ist anders in 1.8.8 für mein setup.

    InformationsquelleAutor initramfs
  2. 1

    War ich in der Lage, herauszufinden, wie man wiederherstellen von subversion-1.8.5 über diesen link:

    trac.macports.org/wiki/howto/InstallingOlderPort

    Zurücksetzen auf 1.8.5 ist das problem gelöst. Ich werde weiter verfolgen Fehlerbehebung was mit 1.8.8 direkt mit den Entwicklern von subversion.

    InformationsquelleAutor Daniel Widdis
  3. 1

    The certificate has an unknown error könnte eine Zertifikatkette problem. Dass ich auf diese nach dem Upgrade von Windows SVN 1.8.3 zu 1.8.7. Sie können für das suchen mit diesem Befehl: echo | openssl s_client -connect host:443

    z.B.

    Certificate chain
 0 s:/[redacted]/
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

    Der Fehler hier ist, dass 1 Thema entspricht nicht 0 ist Emittenten. Fixieren Sie die Zertifikatskette auf dem server.

    • Der Fehler war ein Ergebnis des selbst-signiertes Zertifikat generieren eine neue Art von Fehler in subversion 1.8.8, die wurde nicht richtig behandelt, in den Versionen von Leibeigenen vor 1.3.4, und es waren ein paar Tage überschneiden, in denen ich meine aktualisierten ports. Nun ist alles up-to-date und funktioniert.
    InformationsquelleAutor Kevin Smyth
Schreibe einen Kommentar