locked
Certification Authority RRS feed

  • Question

  • I'm hoping to get some help on a question about certificates that recently came up.  First off, we already have a Server 2008 R2 Certification Authority.  It is used to generate certificates for our DCs.  Recently, the team that handles our Instant Messaging platform (Cisco Jabber) came to the server team to request that clients get issued certificates.  When our Windows 7/10 clients connect to Jabber, they complain about the certificate (error: This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store).  

    My first thought was that we could use our existing AD Certification Authority to solve this problem.  As you can see in the image I've attached, the certificate clients receive from the Jabber device is "server.xxx.local" which is the same domain as the CA.  I found this article describing how to issue client certificates: https://msdn.microsoft.com/en-us/library/cc731242.aspx.  But I feel like I might be chasing the wrong solution.  So that brings me to my question(s):

    Questions:  Is there a way to get all clients in the domain to trust the certificate shown in the screenshot?  Can we use our existing Certification Authority to do this?

    Thanks.  I appreciate anything that could help.

    Edit: Sorry for the absence of a screenshot. I wasn't able to attach it because my account hasn't been verified.  It's a shot of the Certifcation Path tab that shows server.xxx.local and the error: "This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store"


    • Edited by arbiter777 Thursday, April 7, 2016 10:13 PM
    Thursday, April 7, 2016 10:00 PM

Answers

  • Hi arbiter,

    If you're going to start using certificates for varying purposes across the domain, one approach I'd recommend is using Certificate Services in Enterprise mode, as domain clients implicitly trust enterprise authorities meaning it takes the administrative burden off your plate. That said, there's absolutely nothing wrong with using standalone authorities - which is what it sounds like you're doing.

    Assuming your clients are domain-joined then the basic process you need to follow is:

    1. Export a copy of the certificate from each of your authorities (root and intermediate - if you're using the latter). Do not include the private key.
    2. Create a new group policy object that applies to the computers in the domain. The scope of this policy is your choice, but if you're going to cover everything from clients to domain controllers then it's likely the best location is at the domain root (or link it specifically to the relevant OUs if you want to be more proactive about your security - just don't edit the Default Domain or Domain Controller policies).
    3. Within that new group policy, navigate to Computer Configuration/Policies/Windows Settings/Security Settings/Public Key Policies/Trusted Root Certification Authorities and import the root authority certificate you exported in step 1.
    4. (Optional) Within that new group policy, navigate to Computer Configuration/Policies/Windows Settings/Security Settings/Public Key Policies/Intermediate Certification Authorities and import the intermediate authority certificate(s) you exported in step 1.

    If you have workgroup machines you need to cover, then you'll have to go around to each computer and manually import the relevant certificates into the associated locations (i.e. Trusted Root and Intermediate Certification). You can do this using mmc.exe via importing the "Certificates" snap-in and directing it to look at the "Computer" store.

    Cheers,
    Lain

    Thursday, April 7, 2016 11:06 PM

All replies

  • Hi arbiter,

    If you're going to start using certificates for varying purposes across the domain, one approach I'd recommend is using Certificate Services in Enterprise mode, as domain clients implicitly trust enterprise authorities meaning it takes the administrative burden off your plate. That said, there's absolutely nothing wrong with using standalone authorities - which is what it sounds like you're doing.

    Assuming your clients are domain-joined then the basic process you need to follow is:

    1. Export a copy of the certificate from each of your authorities (root and intermediate - if you're using the latter). Do not include the private key.
    2. Create a new group policy object that applies to the computers in the domain. The scope of this policy is your choice, but if you're going to cover everything from clients to domain controllers then it's likely the best location is at the domain root (or link it specifically to the relevant OUs if you want to be more proactive about your security - just don't edit the Default Domain or Domain Controller policies).
    3. Within that new group policy, navigate to Computer Configuration/Policies/Windows Settings/Security Settings/Public Key Policies/Trusted Root Certification Authorities and import the root authority certificate you exported in step 1.
    4. (Optional) Within that new group policy, navigate to Computer Configuration/Policies/Windows Settings/Security Settings/Public Key Policies/Intermediate Certification Authorities and import the intermediate authority certificate(s) you exported in step 1.

    If you have workgroup machines you need to cover, then you'll have to go around to each computer and manually import the relevant certificates into the associated locations (i.e. Trusted Root and Intermediate Certification). You can do this using mmc.exe via importing the "Certificates" snap-in and directing it to look at the "Computer" store.

    Cheers,
    Lain

    Thursday, April 7, 2016 11:06 PM
  • Hi,

    >>Is there a way to get all clients in the domain to trust the certificate shown in the screenshot?

    In brief, you have two options:

    1. Issue the new certificate to the jabber by using your CA server. (I assume that all of your clients trust your CA.)
    2. Import the CA certificate which issues the certificate to jabber server into the trusted root certificate authorities of all clients.

    Best Regards,


    Steven Lee Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Sunday, April 10, 2016 3:33 PM
  • Hi Lain.  Thanks for responding.  Sorry for the delay, I've been in training for the past week.  I understand what you're saying and I think I'm going to stand up the Enterprise CA to make our lives easier.  I'm assuming it can run in tandem with the existing Standard CA?  Also... what our network team has in mind is that they would provide a CSR from their devices that we would sign and give them back a certificate that they can import into their devices that all clients in the domain would trust. Does the process you describe cover that scenario?
    Monday, April 25, 2016 6:14 PM
  • Thanks for the reply Steven.  In those examples, is a .csr generated from the device and signed by the CA?  That's the process the network team seems to have in their head.  Since the jabber server is domain joined, I'm guessing I can use our Windows Server Standard CA to create a certificate but then what about non-domain joined?  Or does that even matter?  I don't believe all clients trust the CA. I'll take up Lain's suggestion and create a Windows Server Enterprise CA.  Do you have any links that describe the two process you mentioned?  I've found a few MS articles regarding CAs but so far I don't think they describe the scenario I'm looking at.
    Monday, April 25, 2016 6:19 PM
  • Hi arbiter,

    If you do go down the enterprise CA route, you don't need the four steps I listed as domain-joined computers will automatically discover those and install the appropriate root and intermediate certificates in the corresponding certificates stores. The four steps I listed are only relevant when you have a standalone certificate authority and wish to deploy that authority's certificate to domain-joined clients.

    So, in short, moving to an enterprise CA will certainly make your administrative life a bit easier. Since I'm saying yes to things, I'll also quickly get the "yes" out of the way for being able to exist side-by-side with your existing standalone CA. There's no problem with that at all, and this is where the four steps I listed will still be of value.

    As a pointer, if you think you're going to start using certificates for a modest number of clients, I'd recommend you look at creating a two-tier PKI model that makes use of an offline root authority and one or more enterprise intermediate authorities as you can grow this intermediate layer continually - and easily, as required.

    Lastly - and bringing this full circle back to Jabber, once you have your intermediate authorities in place, make sure you use the autoenrolment settings within group policy to fully automate the deployment and ongoing renewal of your client certificates. The one tip I'd give you here is to ensure you're completely happy with your template before enabling the "autoenroll" security setting, i.e.:

    1. Create the template (probably by duplicating one of the originally supplied templates).
    2. Do not tick the Autoenroll setting in the Security tab.
    3. Complete your manual testing with Jabber via manually enrolling to obtain a certificate from this template.
    4. When you're happy the template meets your requirements, then go back and enable the autoenroll option.

    This process will ensure you don't accidentally fall into the trap of issuing hundreds or more of a template that doesn't work as expected and keeps the environment clean.

    Autoenrollment is a wonderful feature to leverage but you can easily make a big mess that you can't clean up if you aren't careful in the planning of new template deployment (speaking from my own past mistakes.

    Cheers,
    Lain

    Monday, April 25, 2016 11:13 PM