locked
Client Select Wrong Certificate. RRS feed

  • Question

  • Certificates have been the continually thorn in my side. I feel like since the day it was deemed PKI would be integrated into SCCM I'm Sisyphus but instead of a rock its certificates. Regardless of how much I learn I never make it to the top of the mountain.

    The issue I'm having is this. Out of approx 300 DPs that are configured as all Pull DPs a handful select the DP Cert instead of the client cert. Since both certs use the same source template(workstation auth) and are issued by the same PKI infrastructure I don't know of a way to force the client to select the appropriate certificate. Whats worse is once I export the private key and import it into the SCCM console the client stops working on that machine, meaning the DP stops working on that DP because as we all know Pull DPs rely on the client to get their content.

    There has to be a way for me to deal with this, i just don't know what it is. I can see in the clientIDStartupmgr.log where it runs a check on all the certs in the cert store and on the handful that have this issue they select the DP cert. Then once i create the site server and add the DP role, import the cert, the certificatemaintenance.log starts throwing errors about not being able to access the MP registry keys on the primary. At that point the DP and client are basically useless.

    I tried exporting the private key from the certificate, importing it into the console, then deleting the certificate off the DP. That didn't work either. After I restart WMI and the SMS Agent service the client stops working and i get the above behavior. I'm currently using the /usepki certissuer switch because we migrated over from 07 that had its own stand alone CA that wasn't a PKI. While the switch worked great and most the PDPs work without issue there are about 10 that just keep selecting the wrong certificate and i don't know what to do.

    Inside the console under administration/security there is a certificate node that shows all the certificates that have communicated with the SCCM environment. I saw that some were marked as blocked, and I unblocked them but that made no difference. I still am at a loss as to what that node does. I've blocked certificates but the client continues talking to the environment, it doesn't update the crl so i really have no clue what that certificate area of the console is used for.

    Back to my question. 

    If anyone could come up with a way to identify the client cert and force the client to use it, I'd be in your debt. Is there a way to specify a cert template as part of the client install/configuration parameters? Or if there is a different alternative I'm open to that too. 

    Thanks in advance for any help anyone can provide.

    Cheers,

    -Sam


    • Edited by KeepReading Friday, November 27, 2015 8:14 PM Spelling
    Friday, November 27, 2015 8:09 PM

Answers

  • Well, I think you've got a couple of options:

    • Remove the local distribution point certificate, you only need that certificate to be configured in the console and you don't need it local on the distribution point. Eventually the client should select a the "normal" client certificate during the selection process. If you can't wait for that, reinstall the client;
    • If you don't want to remove the distribution point certificate, make sure that you are aware of the certificate selection process (see article below). Basically when the certificates are similar, the certificate with the longest validity period will be selected;
    • If you don't want to remove the distribution point certificate you can have a look at the CCMCERTSEL client installation property. That might give you some options for specifically selecting a certificate during the client installation.

    For more information please refer to: https://technet.microsoft.com/en-us/library/gg712284.aspx#BKMK_PlanningForClientCertificateSelection


    My Blog: http://www.petervanderwoude.nl/
    Follow me on twitter: pvanderwoude

    Saturday, November 28, 2015 6:59 AM