PKI: Country Code in Nutzer-Zertifikat

[AgentSmith 10]

W2K8 PKI, Autoenrollment, Nutzer-Zertifikate:

===========================================

 

Problem:

In ausgestellten Nutzerzertifikaten ist kein CountryCode (C=DE) enthalten, nur die AD-Infos email, CN, OU usw.

(Im Root/Issuer-Zertifikat ist C=DE ordentlich enthalten.)

Es soll Autoenrollment verwendet werden!

 

Frage:

Wie bringe ich CA02 dazu, in den Zertifikaten den CountryCode (C=DE) einzufügen?

Von wo nimmt sich die Zertifikatsvorlage den CountryCode?

 

Umgebung:

zweistufige PKI, W2008R2

CA01 Root, offline

CA02 Issuer, AD-Integriert

Autoenrollment der Nutzer-Zertifikate per GPO und neu erstellter (kopierter) Zertifikats-Vorlage

Attribut (C=DE) im User-Objekt der AD ist gesetzt.

DN mit C=DE während der Install. der CAs ist gesetzt.

 

Anhang:

Antragsteller Nutzer-Zerti:

E = nutzer@dom.local

CN = Nutzer, Max

OU = Benutzer

DC = dom

DC = local

 

Antragsteller Issuer-Zerti:

CN = CA02

O = xxxxx

C = DE

 

vielen Dank für kompetente Kommentare ;-)

[olc 18]

Hi,

 

das läßt sich meines Wissens leider nicht per Autoenrollment lösen.

 

Du müßtest also "manuell" die Requests erstellen und die entsprechenden Attribute in die Requests kippen - etwa per MMC, AD CS Webseite oder certreq.exe. Certreq.exe ließe sich automatisieren, sprich die notwendigen inf-Dateien ließen sich sicher per Script aus den AD-Attributen eines Systems einfügen.

 

Hinweise zu certreq.exe und den anderen "manuellen" Varianten finden sich hier: How to Request a Certificate With a Custom SAN

Hinweise zur Automatisierung finden sich z.B. hier: http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=11 .

 

Viele Grüße

olc

[AgentSmith 10]

Vielen, vielen Dank! Da hätte ich mir Stunden vergeblicher Suche nach so einem essentiellen Detail sparen können...

 

Schön ist das nicht - jetzt weiss ich, warum in vielen Umgebungen für Signaturlösungen Linux/OpenSSL-PKIs aufgesetzt sind...

 

OK, dann scripte ich das halt (trotz schöner Windows-PKI mit Autoenroll.)...

 

nochmals Danke!

[olc 18]

Hi,

 

ich verstehe den Zusammenhang zwischen der Thematik und Linux/OpenSSL PKI nicht.

 

Bei OpenSSL mußt Du ebenfalls alles selbst erstellen / scripten? Was genau ist der Vorteil dabei, den Du siehst?

 

RedHat hat meines Wissens in der eigenen OpenCA Implementierung eine Art Autoenrollment. Aber auch hier wirst Du meines Wissens nicht um Scripting herumkommen.

 

Viele Grüße

olc

[AgentSmith 10]

Eben! Bei OpenSSL muss ich eh alles skripten, also brauche keine zwei extra W2K8-Server aufzusetzen, wo ich dann, wenns ans Eingemachte geht, auch wieder alles selber basteln muss. Das meinte ich damit...

 

KlickyBunti und viel Komfort geht eben nur solange, wie alles 0-8-15 ist...

 

Na egal... Danke Dir!

[olc 18]

Hi,

 

wenn ich schlecht gelaunt wäre würde ich sagen, es ist kein Problem der PKI, sondern ein Problem mangelhafter Anforderungsdefinition bei der Evaluierung der PKI Deinerseits. ;)

 

Insgesamt hat die MS PKI einen anderen Funktionsumfang und einen anderen Fokus als einige andere Implementierungen (Open Source oder andere Hersteller) - Du mußt also vorher genau schauen, was Du mit welcher Lösung erreichen kannst.

 

Viele Grüße

olc

[AgentSmith 10]

Du hast natürlich grundsätzlich Recht...

... aber wenn ich schlecht gelaunt wäre (und das war ich gestern noch ;-) ), dann würde ich sagen: Wenn so ein grundlegendes Detail wie der Country Code(!) nicht über eine Vorlage mit im Zertifikat landet (wo ja das Attribut schon in AD existiert!), dann ja dann...

... was soll man da noch sagen...

... das wäre ja als würde man vorher prüfen müssen, ob ein neues Auto auch rechts blinken kann, oder nur links...

 

Aber jetzt wirklich egal! Danke für Deine Hilfe - ist ja schnell etwas gescriptet und natürlich hat AD-Integrierte PKI einiges mehr zu bieten, was sich lohnt.