none
Certificate Template Subject Name built from AD

    Question

  • Hi,

    I have configured a certificate template to build from AD and have chosen Common Name for subject and DNS name for the SAN. I was hoping that choosing Common Name that I would get what is in the CN field of the AD object (in this case a computer account). This seems to be alluded to in this article:

    http://technet.microsoft.com/en-us/library/cc753994.aspx

    But after configuring the template in this way, the issued certs have a Subject Name that reads:

    CN = computername.mydomain.local

    And a SAN that reads:

    DNS = computername.mydomain.local

    Why is this happening?

    Thursday, June 26, 2014 5:04 AM

Answers

  • Hi Jeremy,

    I'm assuming what you're looking for is having the Subject Name use a flat NetBIOS-style name rather than an FQDN? If so, I don't believe this is possible using the built-in mechanics within Certificate Services that allow you to choose the Subject Name format (i.e. the options found beneath the Subject Name tab in the new certificate template dialog).

    Keep in mind that a common name as it applies to an LDAP isn't explicitly related to how it's handled in PKI. Both behaviours are normal within their respective realms, i.e. it's expected that the AD "cn" value has the domain namespace added to it as part of a certificate request.

    To get a flat name version of the CN in the Subject Name, you're going to have to handle it either programmatically (which covers running commands like certreq.exe or PowerShell) or create a new template which is designed to require the manual assignment of the Subject Name - which of course is then unusable from an autoenrolment perspective.

    It's probably worth noting that after November 1st, 2015, single label subject names will no longer be trusted, which is as good a reason as any to get out of this long standing "not recommended" practice and switch over to an FQDN approach. It also dictates that the SAN field is mandatory and the subject common name is now deprecated (meaning it can be used but is no longer required).

    I'm sure there's a more official notification somewhere, but this article from a Microsoft blog is as good as any to read on this topic.

    Cheers,
    Lain

    • Edited by Lain Robertson Thursday, June 26, 2014 6:45 AM Changed "not" to "now" (small but important context change).
    • Marked as answer by Amy Wang_Moderator Wednesday, July 16, 2014 7:50 AM
    Thursday, June 26, 2014 6:08 AM
  • I forgot to report back, I re-enrolled for a new cert and then set a scheduled task to run a certutil -pulse every 5 minutes and the re-enrolment worked like a charm.
    Monday, July 14, 2014 10:36 PM

All replies

  • Hi Jeremy,

    I'm assuming what you're looking for is having the Subject Name use a flat NetBIOS-style name rather than an FQDN? If so, I don't believe this is possible using the built-in mechanics within Certificate Services that allow you to choose the Subject Name format (i.e. the options found beneath the Subject Name tab in the new certificate template dialog).

    Keep in mind that a common name as it applies to an LDAP isn't explicitly related to how it's handled in PKI. Both behaviours are normal within their respective realms, i.e. it's expected that the AD "cn" value has the domain namespace added to it as part of a certificate request.

    To get a flat name version of the CN in the Subject Name, you're going to have to handle it either programmatically (which covers running commands like certreq.exe or PowerShell) or create a new template which is designed to require the manual assignment of the Subject Name - which of course is then unusable from an autoenrolment perspective.

    It's probably worth noting that after November 1st, 2015, single label subject names will no longer be trusted, which is as good a reason as any to get out of this long standing "not recommended" practice and switch over to an FQDN approach. It also dictates that the SAN field is mandatory and the subject common name is now deprecated (meaning it can be used but is no longer required).

    I'm sure there's a more official notification somewhere, but this article from a Microsoft blog is as good as any to read on this topic.

    Cheers,
    Lain

    • Edited by Lain Robertson Thursday, June 26, 2014 6:45 AM Changed "not" to "now" (small but important context change).
    • Marked as answer by Amy Wang_Moderator Wednesday, July 16, 2014 7:50 AM
    Thursday, June 26, 2014 6:08 AM
  • It is explained in the details of the enrollment procotol specification:

    There is a flag in an attribute of the template, msPKI-Certificate-Name-Flag, called CT_FLAG_SUBJECT_REQUIRE_DNS_AS_CN

    Quote from the specs:

    If the request is for a machine certificate, the CA MUST set the CN of the Subjectfield of the issued certificate with the dNSHostNameattribute of the requestor's computer object in the working directory.

    These flags cannot be changed with the certtmpl.msc GUI. They could theoretically modified by editing the template with adsiedit but this is not supported and I advise against it.

    You can get the NetBIOS / Common Name in the Subject Name if you don't mind having the full AD Distinguished Name embedded: If you pick the option Fully Distinguished Name in the Subject Tab the CN of the Subject Name will be populated with the CN of the AD object - but other CN, OU and DC components will show up as well.

    Elke

    Thursday, June 26, 2014 6:38 AM
  • Hi Jeremy,

    I'm assuming what you're looking for is having the Subject Name use a flat NetBIOS-style name rather than an FQDN? 

    Yes. That is right. But I've subsequently worked out that even if the Subject is: CN = Computername

    that this isn't a valid match when connecting to the server (via RDP in this case) with the NetBIOS name.

    Very interesting article. I will have to give it a good read tomorrow.

    Thursday, June 26, 2014 6:47 AM
  • It is explained in the details of the enrollment procotol specification:

    There is a flag in an attribute of the template, msPKI-Certificate-Name-Flag, called CT_FLAG_SUBJECT_REQUIRE_DNS_AS_CN

    Quote from the specs:

    If the request is for a machine certificate, the CA MUST set the CN of the Subjectfield of the issued certificate with the dNSHostNameattribute of the requestor's computer object in the working directory.

    These flags cannot be changed with the certtmpl.msc GUI. They could theoretically modified by editing the template with adsiedit but this is not supported and I advise against it.

    You can get the NetBIOS / Common Name in the Subject Name if you don't mind having the full AD Distinguished Name embedded: If you pick the option Fully Distinguished Name in the Subject Tab the CN of the Subject Name will be populated with the CN of the AD object - but other CN, OU and DC components will show up as well.

    Elke

    Ah, thanks for that. I will give it a try.
    Thursday, June 26, 2014 6:48 AM
  • On Thu, 26 Jun 2014 06:48:02 +0000, JeremyHagan wrote:

    Ah, thanks for that. I will give it a try.

    This will still result in a warning when connecting via RDP.


    Paul Adare - FIM CM MVP
    Q. how many lightbulbs does it take to change a light bulb?
    A. one, if it knows its own Goedel number.

    Thursday, June 26, 2014 8:13 AM

  • This will still result in a warning when connecting via RDP.


    Paul Adare - FIM CM MVP

    It did. It would seem that the only way to have an effective RDP TLS cert is via manual enrollment. I am working on a powershell script to achieve a certificate request which has the server's NetBIOS name, FQDN and IP address as SANs. With the ability to auto-renew a manually enrolled cert this should be enough.
    Thursday, June 26, 2014 10:39 PM
  • Hi Jeremy,

    The only thing I'd reinforce with that strategy is what I mentioned above with the changing of the requirements come November 2015 for subject names, SANs and the relationship between the two effectively being reversed.

    You could find all your certificates are treated as invalid after this date using the approach you're proposing. I'd recommend sticking to the certificate request requirements of using an FQDN for both the subject name and SANs so you're future proofing your configurations and absorbing any pain in making the related configuration changes between now and November 2015 rather than at the last minute.

    Cheers,
    Lain

    Thursday, June 26, 2014 11:48 PM
  • The changes outlined are strictly related to certificates issued by a public certification authority and have no impact on what you use your own PKI to do.

    From the article.

    Unfortunately is is completely impractical to expect sysadmins to always use FQDNs when hitting internal servers via RDP and connecting to management web-interfaces or replacing self-signed certificates with enterprise signed ones. 

    One of my key goals is to eliminate certificate warnings wherever possible by using enterprise-CA signed certs or trusting the self-signed cert where they are not possible to replace. This is in an effort to train my sysadmins that a certificate warning is something they need to worry about, not something that they should be clicking through every time they connect to what they THINK is the DC that they are about to enter their Domain Admin credentials into.

    If there are excessive prompts that are OK to ignore then it is harder for them to identify the ones that are not OK to ignore.


    • Edited by JeremyHagan Thursday, June 26, 2014 11:56 PM
    Thursday, June 26, 2014 11:55 PM
  • Hi Jeremy,

    I'm coming more from the perspective that we often see various Microsoft teams - I'm thinking squarely about Exchange and Lync at the moment (as they have more at stake given their "by nature" public presence), adopt change. We know that FQDNs in certificates won't be an issue in any product whereas it's unknown whether the same can be said for flat names.

    Anyhow, it's only a recommendation. As you say, it can be ignored and dealt with later if it becomes relevant.

    As for the administrator's behaviour, all I can say is I feel your pain. I just don't know that I'd pander to them at the expense of good/best practice. I prefer to continue to beat them with the re-education stick - even if I know it's falling on deaf ears.

    Cheers,
    Lain

    Friday, June 27, 2014 12:07 AM
  • Just curious - but did you also populate the SAN in this test?

    Checking the requirements for RDP it seems that either the Subject CN or the SAN needs to contain the FQDN.

    It would be interesting to know if it works by adding the NetBIOS name to the subject CN (by selecting Fully Distininguished Name for the CN) and keeping the DNS Host Name in the SAN.

    Elke

    Friday, June 27, 2014 10:57 AM
  • Hi Jeremy and Lain,

    I agree! I believe the main issue is that the Subject CN (in contrast to the SAN) has originally not been designed as to hold a machine network name - as NetBIOS or FQDN. Part of the larger story of things being tacked on to an old standard based on X.500 directory names.

    I also had my share of experiences with third-party LDAP browsers and VPN clients that refused to work with machine cetificates that had empty CNs but the SAN populated with the FQDN - as DC and Workstation templates are configured by default and is the right way to do it as per RFC.

    Not sure if it helps but that probably should be pointed out to admins, too. I think it is unfortunate in that respect that the IIS wizard also had used the CN ever since and people got trained to putting the machine name (only) into the CN.

    Elke


    Friday, June 27, 2014 11:09 AM
  • Just curious - but did you also populate the SAN in this test?

    Checking the requirements for RDP it seems that either the Subject CN or the SAN needs to contain the FQDN.

    It would be interesting to know if it works by adding the NetBIOS name to the subject CN (by selecting Fully Distininguished Name for the CN) and keeping the DNS Host Name in the SAN.

    Elke

    I tried both Common Name and Fully Distinguished name for the certificates, both with a SAN of the FQDN. In no circumstance would the certificate match for plain host name when connecting to the server with the RDP client.
    Monday, June 30, 2014 12:21 AM
  • Following up on this, I have managed to automate a manual certificate enrolment which will result in a certificate with the DN as the subject and include SAN's for the NetBIOS name, FQDN and IP address (as both IP address and dns SAN) of the server.

    According to http://blogs.technet.com/b/xdot509/archive/2011/07/06/autoenrollment-for-offline-certificate-templates.aspx

    I can configure my servers to automatically renew these certificates (if I am reading it right). But I set up a test with a certificate which is valid for a day and has a renewal period of 1 hour and this didn't renew. I followed the article almost to the letter. Is this an artefact of the short renewal period? When I tried to renew the expired certificate it the CA wouldn't renew it because it was expired.

    Thursday, July 10, 2014 1:45 AM
  • Autoenrollment is triggered by a group policy refresh - so I guess the GPO refresh is not invoked within that 1 hour time slot.

    So you could either plan to run gpupdate /force something like 55 minutes before certificate expiry of pick a longer renewal period for testing.

    Monday, July 14, 2014 4:02 PM
  • I forgot to report back, I re-enrolled for a new cert and then set a scheduled task to run a certutil -pulse every 5 minutes and the re-enrolment worked like a charm.
    Monday, July 14, 2014 10:36 PM