I like to think I have a better understanding of PKI then most people but this one issue has me scratching my head and I was hoping someone could cut to the core of it.

In a system where you have Wireless that is authenticating via certificates and not usernames/passwords, I am confused about the private key sharing across devices or if it even uses the private key for actual authentication.
For example, you have an Apple phone that you want to authenticate via a certificate that is managed by AD and some MDM. When the MDM pushes a certificate to the phone for the user, is the user's private key, assuming it is in AD, pushed to the phone as well? I can see with EAP-TLS where you need to encrypt data so the private key is needed but for authentication it is just a matter of validating that the certificate is authentic and is that user's certificate, which to my understanding a certificate can do with or without a public/private key, right? It appears that the client cert is actually doing double duty as the eap-tls cert for encryption and for authentication, since these seem to be tied together in most implementations the thought occurs that you could have a device specific cert that generated a unique private key to establish the tunnel and a user certificate just used to validate the user without exposing the user's private key to the mobile device. Is this the case or is this normally how it is done and I am just missing that part in some of the explanations.

Lastly, I am not a big fan of certificates used for authentication as it seems to be more of a stored password on the device which can pose a lot of security questions. If AD does share the private key for the user this seems to exacerbate the security issue by allowing all traffic and data to be exposed to that user if a single device is compromised. Am I missing something with this that would make me feel better then I do about certificate-only based authentication?

Thank you

  • 1
    assuming it is in AD what exactly is in AD? which to my understanding a certificate can do with or without a public/private key, and a user certificate just used to validate the user without exposing the users private key to the mobile device um? Can you elaborate these sections as they are unclear. And I really didn't get what is your exact issue.
    – Crypt32
    May 28, 2017 at 16:28
  • I have to admit that some of this is assumption from working with IDM solutions that seem to validate the certificates against Active Directory as well as some other posts I have seen on this forum. For instance when creating a certificate authentication group in Cisco ISE there is an option to validate the certs in AD. Looking this up I found that is says it searches AD for the user and/or workstation cert to compare fields in order to validate. This is what has me scratching my head, I did not think this was supposed to be the case. May 29, 2017 at 3:44
  • The rest was just me trying to explain my understanding in order to try and find where I was making the wrong assumption and try and clarify, apparently unsuccessfully, what I was going for in the question. May 29, 2017 at 3:48

1 Answer 1


Maybe some of following statement are not accurate, but in overall, it works very similarly.

It really depends on implementation. But the idea is the private key never leaves the device it is using it. If so it is wrong design. I don't know any MDM (mobile device management software) as I didn't work with any previously but it will work in very similar way as I describe bellow.

The mobile device (iPhone in your case) will generate private key. It will also create the CSR (certificate signing request - it out of other data includes public part of the generated key), please note the CSR can also be generated by the MDM then delivered to iPhone for signing. Then iPhone signs it (hashes it and encrypts the hash) using the generated private key and send it over the MDM to CA (certification authority) for validation and approval. MDM is responsible for device authentication before the first key is generated, I would say you need to login using AD user name/password for the first time from trusted network without any authentication method, such as 802.1x.

Once the CA will ensure the validity of CSR (this can be also completely manual process) it creates the certificate and signs the certificate using its private key. It stores generated certificate to issued certificates store and passes it back to the MDM. MDM will store it in AD (or not) and send it back to the iPhone device. Once device receives the signed certificate it checks if it has appropriate CSR stored inside (it should as it generated / signed it), pairs the information from signed cert and CSR together and store the certificate including the public and private parts of the key internally (usually to secure certificate store). Private key can be additionally protected using some kind of another protection (i.e. PIN, password, smart card, whatever) so it user mus authorize usage of the key in such case. In iPhone I would say it is protected and encrypted using the user password/pin/fingerprint so once you unlock the phone it can be used.

For authentication, (it does not matter if it is 802.1x EAP-TLS or another TLS or another method using certificates for authentication - everything works similary) you use this certificate signed with CA and usually something signed (encrypted) by your private key related to the certificate. It is usually some kind of challenge sent by the server and it is used to proof you own the private key related to the certificate you sent to server to be used for authentication and you claim it is yours.

Server then checks your certificate (if it is valid - date/time, if it is not revoked, if it is supposed to be used to do the action you are actually trying to do and if it is signed with trustworthy certification authority) then it uses the public part of the key stored in the certificate to decrypt the challenge to make sure you are owner of the certificate (the correct private key was used to sign the data) If the decryption is successful and the challenge matches the challenge sent to you for signing it actually means you are the owner of the certificate and you own the private key related to that certificate.

So what the server needs to know to authenticate you? Just the root CA or immediate CA authority certificate used to sign your certificate, your certificate including your public part of the key and the data encrypted (signed) with your private key related to the certificate. That's enough to authenticate and authorize you. It never needs to know your private key so there is no reason to store it in AD or in CA or wherever else than in your device.

Few words about the AD and MS PKI (CA service) - its same as stated above :):

AD never stores your certificate including private key. Why? Because it simply does not know it. It never did. If you ask for certificate in MS PKI (others work in the same or very similar way - EJBCA, OpenCA...) it usually works in the way you generate the private key on your computer, then you create certificate signing request. This can be done at any place, in case of MS it is on the CA server self service usually. CSR contains i.e.: distinguished name (name or email), your address, what purposes you request the certificate for - ie. authentication, email signing, whatever). Then you get the CSR, and you add some info to it, i.e. public part of the key, fingerprints, whatever. Finally, you sign the CSR (you hash the CSR and you encrypt the hash using your private key) then you send it to the self CA service portal. CA then generates a cert, signs it and delivers it back to you in pre-defined way. I.e. by placing it on the web or by email or, it probably could be integrated with MDM also.

In this case I am not 100% sure the described process works like this in detail but it will be very very close to it.

  • 1
    Thank you for the great post, this does align with my thinking on this and you did clarify and point out where I was getting turned around. It is a little ironic that this was what I was initially thinking but after reading a couple of other posts on the this forum I got turned around into think AD was getting a copy of the Cert. May 29, 2017 at 4:06
  • AD probably gets your cert, but containing the public part of the RSA/EC key only.
    – Fis
    Sep 14, 2019 at 18:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .