PuTTY Key Generator meldet beim Laden einer PEM-Datei, dass der private Schlüssel (kein privater Schlüssel) nicht geladen werden konnte


3

Ich habe ein Zertifikat ("gridcert.p12") im PKCS12-Format, das ich in ein Schlüsselpaar konvertieren möchte, das ich in PuTTY verwenden kann.

Ich verwende OpenSSL, um die PKCS12-Datei in ein Paar PEM-Dateien zu konvertieren, eine für einen privaten Schlüssel, die andere für einen öffentlichen Schlüssel. PuTTY akzeptiert jedoch keine PEM-Schlüssel. Daher versuche ich, den privaten PEM-Schlüssel über den PuTTY-Schlüsselgenerator ("puttygen.exe") in das PPK-Format zu konvertieren. Wenn ich jedoch versuche, den Schlüssel zu laden, gibt der PuTTY-Schlüsselgenerator die Titelfehlermeldung aus.

Meine Arbeitsdokumentation ist unten eingefügt. Alle Ideen werden sehr geschätzt.

# 12:45 22.04.2015 #

goal: convert "gridcert.p12" to a PuTTY-useable keypair.

first, secluded prior work to subdirectory "old attempts".
i decided to keep "gridcert.p12" as-is, rather than regenerate it.

current OpenSSL version is "OpenSSL 1.0.2 22 Jan 2015" by The OpenSSL Project.
no snapshot; just the stable release.
it's meant for a 32-bit system, i think (it's stored in directory "OpenSSL-Win32").

current download of "putty.exe" and "puttygen.exe" from Simon Tatham (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html).
downloaded versions for Windows on Intel x86.
"puttygen.exe": beta 0.64.0.0
"putty.exe"   : beta 0.63.10188.0

using Windows 8.1 on 64-bit Acer laptop.

created mixed public/private key file with:
    13:05:21,98>C:\OpenSSL-Win32\bin\openssl pkcs12 -in gridcert.p12 -out keys.pem -nodes
    Enter Import Password:
    MAC verified OK

created individual private and public keys, respectively, with:
    13:10:40,36>C:\OpenSSL-Win32\bin\openssl pkcs12 -in gridcert.p12 -out privatekey.pem -nodes -nocerts
    Enter Import Password:
    MAC verified OK

    13:11:25,53>C:\OpenSSL-Win32\bin\openssl pkcs12 -in gridcert.p12 -out publickey.pem -nodes -nokeys
    Enter Import Password:
    MAC verified OK

both keys start with "MII" and end with "==".
the private key starts with "MIIEvwIBADANBgk...".
the public key starts with "MIIIxzCCBq+gAwI...".
the mixed-key file corroborates these observations.
both files seem to end with a new-line in both Notepad and Notepad++.
the private key has 1653 characters in its body, counting line breaks (not at the beginning or end).
the public key has 3050 characters in its body, counting line breaks (not at the beginning or end).

opening "puttygen.exe", pushing "Load", and selecting any of "privatekey.pem", "publickey.pem", and "key.pem" generates the error box "Couldn't load private key (not a private key)".
running "puttygen.exe" as administrator and trying to Load "privatekey.pem" generates the same error.

tried recreating public/private keys with no "-nodes" specifier, instead using "-clcerts":
    14:51:12,59>C:\OpenSSL-Win32\bin\openssl pkcs12 -in gridcert.p12 -out publickey_clcerts.pem -clcerts -nokeys
    Enter Import Password:
    MAC verified OK

    15:06:56,17>C:\OpenSSL-Win32\bin\openssl pkcs12 -in gridcert.p12 -out privatekey_clcerts.pem -clcerts -nocerts
    Enter Import Password:
    MAC verified OK
    Enter PEM pass phrase:
    Verifying - Enter PEM pass phrase:

"puttygen.exe" still gives the same error when i try to Load "privatekey_clcerts.pem" and "publickey_clcerts.pem".

the "_clcerts.pem" files look very similar to "privatekey.pem" and "publickey.pem".
their bodies both start with "MII" and end with "=".
i think that the new public key file is the same as the old.
the new private key file is definitely somewhat different from the old.

in "puttygen.exe", tried clicking "Conversions -> Import" and selecting "privatekey.pem", but the same error message was returned.

tried generating a PuTTY key to see if it runs into same problems.
opened "puttygen.exe" and clicked "Generate".
moved mouse in blank space to generate randomness (that is so cool).
entered a passphrase.
clicked "Save private key" and saved it as "privateputty.ppk".
clicked "Save public key" and saved it as "publicputty", no extension.
clicked "Load" and selected "privateputty.ppk".
clicked "Conversions -> Export OpenSSH key", saved it as "privateputtySSH.pem".
clicked "Load" and selected "privateputtySSH.pem".
a box prompted me for the passphrase, which i entered.
a box appeared telling me that i'd successfully imported an OpenSSH SSH-2 private key.
i clicked "Okay"  and the PuTTY Key Generator stood before me.

the PuTTY-generated private key is quite different from the OpenSSL-generated key.
it begins right with "-----BEGIN RSA PRIVATE KEY-----
"; i.e., no header information.
additionally, "privatekey.pem" indicated the key body with "-----BEGIN PRIVATE KEY-----".
instead of launching straight into the body after it's "----" intro, "privateputtySSH.pem" has some header info before its gobbledygook body.
it almost certainly doesn't start the body with "MII", but it's a bit difficult to tell where the body starts.
it terminates the body with "==", like before.
finally, it closes with "-----END RSA PRIVATE KEY-----" and a newline.

Antworten:


6

BEGIN PRIVATE KEYmarkiert das PKCS # 8-Format für private Schlüssel, das OpenSSL seit kurzem verwendet, während PuTTY nur das "traditionelle" / "PEM" BEGIN RSA PRIVATE KEY-Format erwartet .

Führen Sie den Schlüssel durch openssl rsa, um ihn in das alte Format zu konvertieren.

Beide Schlüssel beginnen mit, MII…da auf diese Weise eine ASN.1-Sequenz startet, wenn sie in Base64 codiert ist. In PKCS # 8 ist jedoch zusätzlich der Schlüsseltyp enthalten , anstatt sich auf den PEM-Header "BEGIN…" zu verlassen. Sie können die Unterschiede mit sehen openssl asn1parse.


Das tut es; Vielen Dank!! Ich würde mich steigern, wenn ich könnte.
Jordanien

1
Kleine Klarstellung: OpenSSL insgesamt hat PKCS # 8 schon lange unterstützt, aber einige Kommandozeilenoperationen wurden pkcs122010 auf 1.0.0
umgestellt
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.