Ich bin auf ein interessantes Problem gestoßen. Wir haben ein PHP-Skript, das einen LTL-Versender kontaktiert (https://facts.dohrn.com/). Dieses Skript ist fehlgeschlagen, weil es das SSL-Zertifikat nicht validieren kann. Ich ging auf die Website und stellte fest, dass sie ein GoDaddy SHA2-Zertifikat verwendeten (verwendet dasGoDaddy-Zertifikatspakete – G2, das für SHA2 verwendet wird).
Ich habe die neuste Version von ca-certificateinstalliert und es sieht so aus, als ob sieStammzertifizierungsstelle von Go Daddy – G2aber das ist nicht dasselbe und schlägt bei allen Validierungsformen fehl. Ich konnte es endlich zum Laufen bringen, indem ich das Paket kopierte und es direkt in einer CURL-Anfrage verwendete. Aber das ist nur ein Workaround. Gibt es noch etwas, das ich übersehen habe, wodurch dies funktionieren könnte, ohne die CA direkt zu installieren?
# openssl s_client -connect facts.dohrn.com:443
CONNECTED(00000003) Tiefe=0 OU = Domain Control Validated, CN = facts.dohrn.com
Prüffehler:num=20:Lokales Ausstellerzertifikat konnte nicht abgerufen werden. Prüfrückgabe:1
Tiefe=0 OU = Domain Control Validated, CN = facts.dohrn.com
Prüffehler:num=27:Zertifikat nicht vertrauenswürdig. Prüfrückgabe:1 Tiefe=0 OU =
Domain Control Validated, CN = facts.dohrn.com
Prüffehler:num=21:Erstes Zertifikat konnte nicht verifiziert werden. Prüfrückgabe:1
--- Zertifikatskette 0 s:/OU=Domain Control Validated/CN=facts.dohrn.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure
Certificate Authority - G2
--- Serverzertifikat [Zertifikat entfernt]
-----END CERTIFICATE-----
Betreff=/OU=Domain Control Validated/CN=facts.dohrn.com
Aussteller=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure
Certificate Authority – G2
--- Keine CA-Namen des Client-Zertifikats gesendet
--- SSL-Handshake hat 1470 Bytes gelesen und 563 Bytes geschrieben
--- Neu, TLSv1/SSLv3, Chiffre ist RC4-SHA. Öffentlicher Serverschlüssel ist 2048 Bit. Sichere Neuverhandlung wird NICHT unterstützt. Komprimierung: KEINE. Erweiterung:
KEINE. SSL-Sitzung:
Protokoll: TLSv1.
Chiffre: RC4-SHA.
Sitzungs-ID: 1A23000017A7003411F3833970B7FA23C6D782E663CE0C8B17DE4D5A15DEE1A5.
Sitzungs-ID-ctx:
Hauptschlüssel: F6C9C6345A09B7965AF762DE4BEFE8BDD249136BF30D9364598D78CF123F17230B0C25DD552F103BEF9A893F75EAD2B0
Schlüsselargument: Keines
Krb5 Auftraggeber: Keines
PSK-Identität: Keines
PSK-Identitätshinweis: Keines
Startzeit: 1432044402
Zeitüberschreitung: 300 (Sek.)
Rückgabecode überprüfen: 21 (das erste Zertifikat konnte nicht überprüft werden)
Antwort1
Es scheint, dass der Webserver unterhttps://facts.dohrn.com/beinhaltet nicht das Zwischenzertifikat.
Dies scheint ein Konfigurationsfehler ihrerseits zu sein. Es ist definitiv zu erwarten, dass es Kompatibilitätsprobleme verursacht, da Sie sich eigentlich nur darauf verlassen sollten, dass die Clients die Stammzertifikate bereits installiert haben.
Siehe die Zertifikatskette, z. B. von derSSLLabs-Ergebnis: (Sie werden auch feststellen, dass es viele andere Probleme mit ihrer SSL-Einrichtung gibt.)
1 Sent by server facts.dohrn.com
Fingerprint: 823e3a70f194c646498b2591069b3727ad0014d9
RSA 2048 bits (e 65537) / SHA256withRSA
2 Extra download Go Daddy Secure Certificate Authority - G2
Fingerprint: 27ac9369faf25207bb2627cefaccbe4ef9c319b8
RSA 2048 bits (e 65537) / SHA256withRSA
3 In trust store Go Daddy Root Certificate Authority - G2 Self-signed
Fingerprint: 47beabc922eae80e78783462a79f45c254fde68b
RSA 2048 bits (e 65537) / SHA256withRSA
Ich würde sagen, dass Ihre wichtigsten Optionen darin bestehen, entweder zu versuchen, den Dienstanbieter davon zu überzeugen, seinen Dienst zu reparieren, oder das Problem auf Ihrer Seite zu umgehen, indem Sie dem Client die Zertifikate zur Verfügung stellen, die sein Server bereitstellen sollte.