Before the description starts please notice that the SMTP based replication of Microsoft ADS doesn't work with TTPs. Microsoft officially commits this problem but doesn't comment the reasons. If you don't use SMTP replication then you can TTPs without any problems except that Microsoft's automatic certificate renewal does not work of course.
The requirements are described in detail in the knowledge base article 291010. The most important things are listed here:
There must be at minimum one CDP.
The X.509v3 extension Key Usage must
include the options Digital Signature
and
Key Encipherment
.
The X.509v3 extension Extended Key Usage
must include
Client Authentication (1.3.6.1.5.5.7.3.2)
and
Server Authentication (1.3.6.1.5.5.7.3.1)
.
This is
necessary because domain controllers will be connected as
servers and establish connections as clients to other servers.
The X.509v3 extension Subject Alternative Name
must include the globally unique identifier (GUID) of the
domain controller and the DNS name of the domain controller.
The GUID is a 16 Byte long number which identify the object of
the domain controller in the directory (ADS). The OID of the
GUID in the othername is 1.3.6.1.4.1.311.25.1
.
There must be one extension with the BMP value
DomainController
inside. Microsoft has an
extra extension for this template name with the OID
1.3.6.1.4.1.311.20.2
. The extension is
referenced by Microsoft as
Certificate Template Name.
The X.509v3 extension Basic Constraints
should include End Entity
as
subject
(OpenSSL: CA=false) and no limitation
for the path length.
The subject of the certificate can be the directory path of the domain controller. This is only optional.
If you want to create such a certficate then you must create the key pair with RSA/Schannel CSP. The most simple way for doing this is to install Microsoft CA services and to issue a certificate request using a form, where you can choose this CSP and generate a key pair and certificate request in PKCS#10 format.
The settings for Key Usage, Extended Key Usage and the CDPs is
no problem with OpenSSL and we don't describe here in detail how
you can configure this in
OPENCADIR/etc/openssl/extfiles/domaincontroller.ext
.
The Basic Constraint and Subject stuff is the same like for
every other certificate too.
The Subject Alternative Name is the first difficult thing. OpenSSL 0.9.7 does not support othername. The solution is to encode the GUID in binary format into the subject alternative name.
You can find a detailed description of DER:
in openssl.txt
of the OpenSSL
documentation. 2.5.29.17
is the OID of the
subject alternative name. The example GUID is
01020304050607080910111213141516
. Please
remember that the GUID is allways a 16-byte string and the
numbers are hexadecimal encoded. A 16 is a decimal 22. The
DNS name is dns.somehost.de
(64:6E:73:2E:73:6F:6D:65:68:6F:73:74:2E:64:65
).
If you need more infos about ASN.1 encodings then please read
the ASN.1 specs. We only know that the 10 in front of the GUID
and the 0F in front of the DNS name are the length of the
values.
The next complicated stuff is the certficate template name but this is a fixed extension so we can copy it from already existing certificates :)
After you read all these complicated issues you understand perhaps why I can only recommend you to use OpenSSL 0.9.8 if you want to issue certificates for domain controllers. The biggest problem is the subject alternative name which can only be created in binary format which requires to change the extension configuration file of the used role for every issued certificate to encode the correct GUID and DNS name of the domain controller. Nevertheless you can do it with OpenSSL 0.9.7.
The first important note before you start with OpenSSL 0.9.8 - you cannot compile OpenCA with OpenSSL 0.9.8. You must install OpenCA with an OpenSSL 0.9.7 and then you must change the path of the OpenSSL binary from the 0.9.7 binary to the 0.9.8 binary. We know that this is not really comfortable but the header files changed from 0.9.7 to 0.9.8 in an incompatible way and we only migrate our sources if there is a 0.9.8 stable release.
The standard things like Key Usage, Extended Key Usage, Subject, CDPs and Basic Constraints do not change between the different OpenSSL versions. The certificate template name extension of Microsoft must be copied as binary too but it is like the other standardized extensions a static string.
The important improvement of OpenSSL 0.9.8 is the support for
othername
in the subject alternative name. The
new OpenSSL version allows a much easier specification of
proprietary extensions even if they are in binary format.
The GUID is the same GUID like in the example for OpenSSL 0.9.7.
The big question is now how can I put it into my OpenCA?
The answer is short. You have to choose otherName as attribute
for the subject alternative name at the RA interface and then
you have to enter
1.3.6.1.4.1.311.25.1;FORMAT:HEX,OCT:01020304050607080910111213141516
.
We know that it is a big problem for the most admins to enter
OIDs and cryptical things like OpenSSL formats. Therefore we
added some extra stuff for Microsoft only. You can use the
field MS_GUID
as a subject alternative name
attribute too. There you have only to enter the pure GUID in
HEX format. The rest is handled by OpenCA.
The requirements are described in detail in the knowledge base article 281245. Please note that we only list the requirements for the PKI system here. There are several other requirements to which you can find in the knowledge base article. The most important things are listed here:
There must be at minimum one CDP.
The X.509v3 extension Key Usage must
include the options Digital Signature
.
The X.509v3 extension Extended Key Usage
must include
Client Authentication (1.3.6.1.5.5.7.3.2)
and
Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
.
The X.509v3 extension Subject Alternative Nme
must include the universal principal name (UPN) of the user.
A UPN is the like account@domain
(e.g.
john_doe@company.com
). It is important to
understand that this is no emailaddress. The OID of the UPN
is 1.3.6.1.4.1.311.20.2.3
. The format of the
UPN is UTF-8.
The X.509v3 extension Basic Constraints
should include End Entity
as
subject
(OpenSSL: CA=false) and no limitation
for the path length.
Please use the patch for OpenSSL which you can find at our ftp
server. The patch othername.tgz
includes a
fix for Microsoft's othername usage. The following documentation
only refers to this patched version of OpenSSL.
OpenCA's role User
already includes the
required extensions for Microsoft's smartcard logon.
Generally you can add the OID for secure email
(1.3.6.1.5.5.7.3.4) and other
things to such a certificate. The smartcard certificate is not
limited to logon. To be more Microsoft-like you can add a
certificate template name to the certificates like for domain
controllers. This is not required but it looks more nice :)
Now we have to deal with the UPN. This UPN must be placed in the
othername
of the subject alternative name. If
you use the patched option and the othername
is
supported by the RA configuration then you have to enter
1.3.6.1.4.1.311.20.2.3:UTF8String:account@domain
in the value field after you selected
otherName
. The keyword UTF8String
is case-sensitive. If you do all correct then you can now issue
a wonderful certificate for smartcard logon.
The only difference between OpenSSL 0.9.8 and 0.9.7 is the
handling of the othername. OpenSSL 0.9.8 support this by default
without patching. You have to enter
1.3.6.1.4.1.311.20.2.3;UTF8:account@domain
.
Please notice that OpenSSL 0.9.8 uses UTF8 and not UTF8String.
We know that it is a big problem for normal users to enter
OIDs and other cryptical things like which have nothing to do
with the UPN. Therefore we added some extra stuff for Microsoft
only. You can use the field MS_UPN
as a
subject alternative name attribute too. There you have only to
enter the pure UPN like an emailaddress. The conversion to
OpenSSL's format is handled by OpenCA.
The private keys of a user are stored in the profile of the user if no smartcards are used. This means that the private keys of any Microsoft client software like Internet Explorer or Outlook are automatically present after a successful login because they are part of the profile. This protects the keys too.