DC certificates for LDAPS

  • 225 Views
  • Last Post 27 May 2016
mikeward posted this 27 May 2016

Hello everyone,   We are trying to setup 3rd party certs on DC’s using KB321051 and have some questions. 

1.  Can we use wildcard certificate for this purpose?  I have found a couple of links that say you can but have not found any documentation or seen examples.

2.  Regardless if we use wild card certs or not, can we add alternate Subject Alternative Names to the cert?  We have been using https://technet.microsoft.com/en-us/library/ff625722%28v=WS.10%29.aspx to accomplish this.  However, the SAN did not show correctly on certificate we received.   Maybe we’re trying to get too fancy with the SAN and should just use the Subject with the FQDN of the DC - but what if an application is binding to the IP, DN or domain name?   This is an example of the request.inf file we used:   ;----------------- request.inf ----------------- [Version]

Signature="$Windows NT$

  [NewRequest] Subject = "C=CA, S=British Columbia, L=Vancouver, O=Contoso, CN=DC1.contoso.com" KeySpec = 1

KeyLength = 2048

Exportable = TRUE

MachineKeySet = TRUE

SMIME = False

PrivateKeyArchive = FALSE

UserProtected = FALSE

UseExistingKeySet = FALSE

ProviderName = "Microsoft RSA SChannel Cryptographic Provider"

ProviderType = 12 RequestType = PKCS10

KeyUsage = 0xa0

  [EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication OID=1.3.6.1.5.5.7.3.2 ; Client Authentication   [Extensions] ; Subject Alternative Name (SAN) 2.5.29.17 = "{text}" continue = "dns=DC1.contoso.com&" continue = "dns=contoso.com&" continue = "dn=CN=DC1,OU=Domain Controllers,DC=contoso,DC=com&" continue = "ipaddress=192.168.1.1&" ;-----------------------------------------------   Thank you, Mike  

Order By: Standard | Newest | Votes
mikeward posted this 27 May 2016

Thank you for all of the suggestions, they are very helpful!

 

Mike



 

show

mikeward posted this 27 May 2016

That is a good command to verify.  I did use

https://ssltools.websecurity.symantec.com/checker/ to verify the cert before sending and some of the SAN appeared to worked.  But when we received the cert back from the 3rd

party it had none of the SAN names and included a new

www.dc1.contso.com
cert. 

 

I did a verify with the command you gave and it looks like all the SAN names are listed.  I wonder if it’s an issue with the 3rd party?

 



Mike



 

show

a-ko posted this 27 May 2016

I forgot…. Key Usage has: Digital Signature, Key Encipherment, which your INF file includes (a0). 

show

bdesmond posted this 27 May 2016

You can use a wildcard but it doesn’t really help. The DC’s name has to be in the subject of the cert or the /first/ SAN entry. AD stops looking after that to see if it’s a valid cert.



 



Thanks,

Brian Desmond

 

w – 312.625.1438 | c – 312.731.3132



 

show

a-ko posted this 27 May 2016

Take a look at the “Kerberos” Certificate Templates in an AD-Integrated CA to see what your Domain Controllers need. The below is the example taken from my production environment. The AD-Integrated “Kerberos” Template supersedes “Domain Controller” and “Domain Controller Authentication” templates for Windows. Although the latter 2 are auto-enrolled when an Enterprise CA is stood up. I’ve seen scenarios where OpenLDAP servers and clients also do not like subjects being filled out and not validating against the Subject field. I never quite understood why this is the case, because HTTPS validates fine against the Subject field. Helped someone track this down on IRC a while back when he was using OpenLDAP. I’m not particularly sure why the Kerberos template includes Smart Card Logon for a DC (maybe to help with validating smart cards?). The KDC Enhanced Key Usage policy is used for PKINIT (http://web.mit.edu/Kerberos/krb5-1.13/doc/admin/pkinit.html) and should be included on your DC Certificates. -Mike Cramer  Key Size: RSA-2048Signature Algorithm: SHA256 Subject field is empty SAN field has: DNS Name=server.domain.comDNS Name=domain.comDNS Name=DOMAIN Enhanced Key Usage Policies: Client Authentication (1.3.6.1.5.5.7.3.2)Server Authentication (1.3.6.1.5.5.7.3.1)Smart Card Logon (1.3.6.1.4.1.311.20.2.2)KDC Authentication (1.3.6.1.5.2.3.5) Application Policies (matches the EKU policy above)  

show

barkills posted this 27 May 2016

Dunno about wild-cards. The CN must be the FQDN of the DC. You can have subject alternative names.



 

We do that because some 3rd party libraries (a Java one, if memory serves) make the assumption that the CN of the cert must match the hostname you are trying to contact. I know some others address

this type of issue by putting their DCs behind a load balancer.

 

show

BrianB posted this 27 May 2016

Mike,

 

You can use the following to verify what the format of the cert will be before sending so that you will know what to expect upon receipt of a paid cert.



 

CertUtil -decode cert.txt cert.cer

then certutil -dump cert.cer

 

I tried to look at it based upon the certreq you sent but received the error: CertUtil: -decode command FAILED: 0x8007000d (WIN32: 13 ERRORINVALIDDATA).



 

Brian Britt

 

show

Close