VPN-Zugriff von Mac OS High Sierra auf zwei Sophos UTM 9 – Boxen: Auf Box 1 klappt der VPN-SSL-Zugriff ohne Probleme. Das Zertifikat von Box 2 lehnt Tunnelblick mit einem „VERIFY ERROR“ ab. Suche und Lösung waren zwar nicht schwer, aber verstanden habe ich es nicht so recht.
Zum Hintergrund: Von einer Sophos UTM (früher Astaro) lädt man sich aus dem User Portal am Mac seine *.ovpn-Datei herunter und zieht sie ins Tunnelblick Fenster. Tunnelblick als Beispiel für einen VPN-GUI-Client. Eine ovpn-Datei enthält entweder eine Config mit den Zertifikaten oder auch die drei *.crt-Dateien einzeln.
Beim Verbinden bekomme ich auf Box 2 beim TLS-Handshake die Meldung:
2017-11-04 12:35:14 us=870806 VERIFY ERROR: depth=0, error=format error in certificate’s notAfter field: C=de, L=Cologne, O=…
2017-11-04 12:35:14 us=871222 OpenSSL: error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed
2017-11-04 12:35:14 us=871432 TLS_ERROR: BIO read tls_read_plaintext error
2017-11-04 12:35:14 us=871638 TLS Error: TLS object -> incoming plaintext read error
2017-11-04 12:35:14 us=871843 TLS Error: TLS handshake failed
2017-11-04 12:35:14 us=872075 Fatal TLS error (check_tls_errors_co), restarting
Und Tunnelblick geht in eine Reconnect-Schleife.
Beanstandet wird scheinbar das „Gültig-Bis-Datum“ im Zertifikat. Das sieht im Klartext der Config (kleines Zahnrädchen am unteren Fensterrand von Tunnelblick zeigt sie an) aber eigentlich ganz valide aus:
Not After : Sep 6 09:36:36 2036 GMT
Da Tunnelblick das Datum nicht aus dem Klartext, sondern aus dem Zertifikatsblock selbst liest, kopiere ich dessen Inhalt zwischen
—–BEGIN CERTIFICATE—–
…
—–END CERTIFICATE—–
in eine Textdatei ca.crt
Die kann man sich in der Mac OS Schlüsselbundverwaltung oder auch gleich im Terminal anzeigen lassen:
bjoern$ openssl x509 -in ca.crt -noout -dates
notBefore=Apr 22 09:36:36 2009 GMT
notAfter=Sep 6 09:36:36 2036 GMT
Auf einer tieferen Ebene kommen diese Datumswerte raus:
bjoern$ openssl asn1parse -in ca.crt | grep „TIME“
193:d=3 hl=2 l= 13 prim: UTCTIME :090422093636Z
208:d=3 hl=2 l= 13 prim: UTCTIME :360906093636Z
Zuerst dachte ich, das zweistellige Jahr am Anfang hätte das falsche Format, aber das scheint zum Standard zu gehören: Ähnlich wie bei zweistelligen Jahreszahlen zum Jahr-2000-Wechsel interpretiert man das Jahrhundert laut RFC3280 Punkt 4.1.2.5 vor/ab 2050 entsprechend dazu: „Where YY is less than 50, the year SHALL be interpreted as 20YY“
Außerdem verwendet das Zertifikat von Box 1 – korrekterweise – auch so ein Datumsformat.
Das Absurde aber: Openssl gibt mir – anders als Tunnelblick – im Terminal auch keinen Fehler aus.
bjoern$ openssl verify ca.crt
ca.crt: C = de, L = Cologne, O = …
error 18 at 0 depth lookup:self signed certificate
OK
(Gut, beide Zertifikate sind selbst signiert. Halte ich in diesen Kontext bis auf die fehlende Revocation von selfsigned certificates für unbedenklich.)
Aber es fällt auf, dass sich die von Mac OS verwendete SSL-Bibliothek von der mit Tunnelblick gelieferten unterscheidet.
bjoern$: openssl version
LibreSSL 2.2.7
Irgendwas scheint sich zwischen der von Apple verwendeten 2.2.7 und der 2.5.5 von Tunnelblick getan zu haben. Für meinen Problemfall habe ich bei Google aber nichts gefunden.
Ein generelles Umstellen der OpenVPN-Version in Tunnelblick von „LibreSSL“ auf „OpenSSL“ brachte auch Box 2 nicht mehr in Schwierigkeiten.
Aber bedeutet das, die Version LibreSSL 2.5.5 wäre buggy? Wahrscheinlich nicht, denn dann hätten beide Zugriffe nicht funktionieren dürfen. Möglicherweise spielt der Signatur-Algorithmus mit rein, denn Box 1 verwendet den – mittlerweile auch veralteten – SHA1 und die Problembox 2 sogar was Schlimmeres. Vielleicht kann das jemand bei sich nachvollziehen. Oder vielleicht besser nicht: Wäre schon längst Zeit für ein Update auf mindestens SHA256 gewesen! Man muss dazu leider so viele Sachen anfassen. Steht als nächstes an!
Links:
https://www.heise.de/security/artikel/Kryptographie-in-der-IT-Empfehlungen-zu-Verschluesselung-und-Verfahren-3221002.html