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.