Das gleiche Problem hatte ich bei Charles Proxy in Kombination mit Wireshark.
Ich denke, das Problem ist, dass Charles zwei (oder mehr) Zertifikate an den Client sendet (überprüfen Sie die Zertifikatnachricht, die vom Proxy an den Client gesendet wird). Wireshark verwendet dann das erste Zertifikat in dieser Liste, das wahrscheinlich nicht mit dem von Ihnen generierten privaten Schlüssel übereinstimmt.
(Genau das fragt sich Benutzer dave_thompson_85 in den Kommentaren.)
Ich habe dies überprüft, indem ich das Zertifikat von Wireshark extrahiere. Beachten Sie, dass Wireshark das Zertifikat im .der
Format extrahiert . Dann habe ich die .der
-Datei in ein .pem
Zertifikat umgewandelt:
openssl x509 -inform DER -outform PEM -text -in wireshark_charles.der -out wireshark_charles.pem
Ich habe das auch .pem
in ein konvertiert .crt
, aber das ist nicht notwendig.
Zertifikat von Charles an den Kunden gesendet
$ openssl x509 -noout -modulus -in wireshark_charles.crt | openssl md5 7a37a32781daf79402623c19ac9c8d7f
Benutzerdefiniertes Zertifikat in Charles eingerichtet
$ openssl x509 -noout -modulus -in charles_custom.crt | openssl md5 62ea5ed061fca62efaaecbbb0226b08e
Der entsprechende private Schlüssel
$ openssl rsa -noout -modulus -in charles_custom.pem | openssl md5 62ea5ed061fca62efaaecbbb0226b08e
Der Modul des von Charles gesendeten Zertifikats stimmt nicht mit dem Modul des benutzerdefinierten privaten Schlüssels überein.
Und wireshark protokolliert dieses Problem auch während der SSL-Dissection:
ssl_decrypt_pre_master_secret wrong pre_master_secret length (128, expected 48) ssl_generate_pre_master_secret: can't decrypt pre master secret
Charles generiert ein neues Pro-Host-Zertifikat, wobei das benutzerdefinierte Zertifikat als Stammzertifikat verwendet wird. Leider habe ich keinen Weg gefunden, diesen von Charles generierten privaten Schlüssel pro Host zu extrahieren. Ich schlage vor, Burp Proxy zu verwenden. In Burp können Sie auswählen, welche Art von Zertifikat Sie verwenden möchten.