Private Key Export trotz gegenteiliger Template-Einstellung

  • Article

Hallo zusammen, Fabian hier. Ab und an erreichen uns Fragen zum Export von privaten Schlüsseln, etwa von Benutzerzertifikaten – hier wundern sich die CA-Administratoren bzw. CA-Manager, daß der private Schlüssel eines Zertifikats am Client exportiert werden kann, obwohl dies im Template nicht erlaubt wurde:

Template 
Beispiel: UserSignatureNoKeyExportTemplate auf einer CA

 4
Der Export auf einem Client ist trotz gegenteiliger Template-Einstellung möglich

Im Normalfall handelt es sich bei den Konstellationen, in denen diese Fragestellung auftritt, nicht um per Autoenrollment erzeugte Zertifikate, sondern um ein Enrollment mittels Windows Server 2003 Web-Enrollment, “certreq.exe” Anforderungen oder aber sehr häufig seit Windows Vista um ein MMC Enrollment.

Spätestens sehr “sichtbar” ab Windows Vista / Windows Server 2008 gibt es nämlich im Vergleich zu WIndows XP / 2003 weit mehr Möglichkeiten, einen Zertifikat-Request mittels MMC zu beeinflussen. Die MMC Dialoge bieten seit Vista / 2008 die Option, fast alle Einstellungen eines Zertifikatrequests mittels GUI zu verändern. So also auch das Erlauben des “private key export”:

1

2 

Wird die Option “Make private key exportable” nun wie im Beispiel oben über die MMC oder aber "certreq.exe" bzw. über das Windows Server 2003 Web-Enrollment gesetzt, überschreibt diese Request-Einstellung die Template-Einstellung – schließlich wird der Zertifikatrequest auf dem Client erstellt und somit auch der private Schlüssel auf dem Client erzeugt als auch vorgehalten und nicht etwa auf der CA. Die Option des privaten Schlüsselexports wird also auf dem Client gespeichert und nicht von der CA festgelegt.

Die CA stellt “lediglich” anhand des Zertifikat-Requests den öffentlichen Schlüssel (also auch das Zertifikat) aus und versieht es mit den notwendigen Informationen. Diese Informationen stammen teils aus dem Request, teils sind es Informationen, die nur die CA angeben kann / darf.

Der Request eines Benutzers für ein Zertifikat und das dazugehörige private Schlüsselmaterial steht somit also nur auf dem Client zur Verfügung, auf dem der Request erzeugt wurde (außer es werden Roaming Profiles bzw. Credential Roaming eingesetzt). Man findet Benutzer-Requests, die noch nicht durch die CA-Manager bzw. CA-Administratoren freigegeben wurden, auf einem Client an folgender Stelle: %SYSTEMROOT%\Users\<BENUTZERNAME>AppData\Roaming\Microsoft\SystemCertificates\Request\Certificates

3

Einen solchen Request und seine Optionen kann man sich recht einfach über die MMC oder aber per “certutil.exe” anzeigen lassen (folgend ein Ausschnitt der certutil-Ausgabe):

C:\Users\Administrator>certutil -v -store -user REQUEST REQUEST
================ Certificate 0 ================
X509 Certificate:
Version: 3
Serial Number: 4295939833ac3d944d6e06e719adebdc
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
Algorithm Parameters:
05 00
Issuer:
EMPTY

NotBefore: 26.01.2010 12:27
NotAfter: 26.01.2011 12:47

Subject:
EMPTY

  […]

Certificate Extensions: 7
1.3.6.1.4.1.311.21.7: Flags = 0, Length = 2d
Certificate Template Information
Template=UserSignatureNoKeyExportTemplate(1.3.6.1.4.1.311.21.8.1352962.8
910182.8211339.1268024.15973616.87.7443111.594514) Major Version Number=100
Minor Version Number=3

    2.5.29.37: Flags = 0, Length = 16
Enhanced Key Usage
Client Authentication (1.3.6.1.5.5.7.3.2)
Secure Email (1.3.6.1.5.5.7.3.4)

    2.5.29.15: Flags = 1(Critical), Length = 4
Key Usage
Digital Signature (80)

[…]

Signature matches Public Key
Root Certificate: Subject matches Issuer
Key Id Hash(rfc-sha1): 57 f9 8a 70 27 14 f7 2d 67 e0 a8 e2 28 74 4d 90 db 42 08
1b
Key Id Hash(sha1): bc 0f 58 9b 8d cc 9f d9 3f cf 1d 29 00 30 2c ea 9d 6c f8 83
Cert Hash(md5): d9 fc 45 e0 2b 5e 30 78 d3 1f 56 c0 a7 d5 c6 c8
Cert Hash(sha1): c2 0a bb 27 41 74 dd f9 f1 f7 a0 44 46 2a 29 2a 03 f0 66 89

[…]

  CERT_KEY_PROV_INFO_PROP_ID(2):
Key Container = 8a37c5692f3f73f2a2f903e9fb1a16e7_0ef9a270-4d27-4249-b4fc-e4b
516462828
Simple container name: le-UserSignatureNoKeyExportTemplate-e170b062-d436-4660-
b0ff-4f140ff849ab
Provider = Microsoft Enhanced Cryptographic Provider v1.0
ProviderType = 1
Flags = 0
KeySpec = 2 -- AT_SIGNATURE

  CERT_SHA1_HASH_PROP_ID(3):
c2 0a bb 27 41 74 dd f9 f1 f7 a0 44 46 2a 29 2a 03 f0 66 89
Simple container name: le-UserSignatureNoKeyExportTemplate-e170b062-d436-4660-
b0ff-4f140ff849ab
PP_KEYSTORAGE = 1
CRYPT_SEC_DESCR -- 1
KP_PERMISSIONS = 3f (63)
CRYPT_ENCRYPT -- 1
CRYPT_DECRYPT -- 2
CRYPT_EXPORT -- 4 CRYPT_READ -- 8
CRYPT_WRITE -- 10 (16)
CRYPT_MAC -- 20 (32)

[…]

Private Key:
PRIVATEKEYBLOB
Version: 2
aiKeyAlg: 0x2400
CALG_RSA_SIGN
Algorithm Class: 0x2000(1) ALG_CLASS_SIGNATURE
Algorithm Type: 0x400(2) ALG_TYPE_RSA
Algorithm Sub-id: 0x0(0) ALG_SID_RSA_ANY
0000 52 53 41 32 RSA2
0000 ...
048c
Signature test passed
CertUtil: -store command completed successfully.

Den entscheidenden Hinweis auf den möglichen Export des privaten Schlüssels liefert und das oben im Request angegebene Flag “CRYPT_EXPORT -- 4”. Siehe dazu CryptGetKeyParam https://msdn.microsoft.com/en-us/library/ee497956.aspx

CRYPT_EXPORT Allows exporting of the key

Somit ist nach der Erstellung des Zertifikats durch die CA und das Zuordnen des Zertifikats zum privaten Schlüssel auf dem Client auch der Export des privaten Schlüssels möglich. Das Verhalten ist dementsprechend so gewünscht bzw. “by design”.

Führt man den Vorgang mittels Autoenrollment durch, anstatt eine manuelle Beantragung vorzunehmen, werden aufgrund der fehlenden eigenen Angaben zum privaten Schlüsselexport die Template Einstellungen genutzt – in unserem Beispiel oben also der Export des privaten Schlüssels unterbunden.

Viele Grüße
Fabian