VPN with client certificate via managed PKI - where did private key come from?

Question

$company allows Mac users to request a client certificate via Symantec PKI to connect to their SSL VPN server. This process involves going to a specific Symantec website (has some sort of ID to identify $company) and entering your name ("Common Name") and Email address. Once approved by a company admin it gives you a link which downloads a .cer file, and when this is imported into Keychain there is a user-named Certificate and a private key linked to it.

Where did that private key come from? It doesn't appear in the .cer file (which appears to be 3 certificates bundled in PKCS#7 format). Is there some trigger when imported that tells Keychain to go and fetch a private key from the PKI server? Is there any generic tool (e.g. openssl) to do that on Linux?

Edit:

The .cer file contains a certificate with CN=MyNameHere (the user), an Issuing CA certificate belonging to $company, and an Intermediate CA certificate also belonging to $company.

Here's an article explaining how to export the private key under windows, but unfortunately doesn't explain how the private key got there either.

Here's another doc from a Mac perspective about exporting the private key, but again doesn't go into how the key gets there in the first place.

Answer 1

I am taking a slight guess, however, I suspect that in browser is using generateCRMFRequest and importUserCertificate in combination. An overview of the process is given by the deprecated Javascript_crypto documentation for Firefox.

Similar things can be achieved with Internet Explorer. I haven't looked but I imagine Safari has some level of support too.

These are entirely non-standard extensions, and according to this post on the CA/Browser forum, not the future.

The key is generated locally, however, it is hard to tell whether or not the key is also sent to the CA for "archival" as in generateCRMFRequest. Since the javascript has access to the generated key, it could conceivably send it over the internet.

Final bit of info, is there a generic tool to do this in Linux? Not to my knowledge. You can certainly go through the process of:

openssl genrsa ... -out private.key
openssl req -new ... -inkey private.key -out certplease.csr

sending certplease.csr to the CA. From them you would get back a PKCS#7 certificate signed by them (and possibly other certificates in the chain, in case they are needed).

However, I don't believe there is a standard user-based private key store in Linux - rather, each desktop environment has a slightly different one.

Answer 2

This is a fascinating question.

First, some thoughts about the .cer file you get: Check out the list of PKCS standards; PKCS#7 is just a container for transporting signed / encrypted data, that doesn't tell us anything about what that data might be. If the data inside was in PKCS#12 format then it's entirely possible that the private key was bundled with it. I guess the important question there is: did you have to enter a password as part of importing the .cer?

Symantec Managed PKI

There are some hints (but no answers) in the Symantec™ Managed PKI Service Deployment Options guide.

You are clearly describing

2.1.1 Native browser enrollment

The native browser enrollment requires no software to be installed on the end user’s computer, and works in both cloud and hybrid scenarios.

Although it's rather lacking in details about where the key is generated.

Having the server generate a private key for you and bundle it into the .cer file would be consistent with sentences like this:

... This option is important in terms of ensuring that high security certificates, such as a smart card or USB token, end up in the appropriate store.

Since certificates are, by definition, public, the only way the phrase "high security certificates" makes any sense is if there's a private key bundled with it.

They also make a lot of references to Microsoft Active Directory enrolment / key management services. But that doesn't explain your Linux case.

Edit: Duh. Something else that's possible is that the browser has access to the OS's crypto functionality (for example Microsoft CAPI) and the javascript on the enrolment page gets the OS to create a private key, and generate a certificate request including a proof-of-possession of that key.

Answer 3

The private key is generated by the client creating the certificate request. When the client imports the certificate, the Keychain application automatically recognises that this certificate is for that specific private key.

Answer 4

I am not sure about Symantec, but Comodo few years ago (~2012) used html5 keygen for this purpose. Keygen tag generates SPKAC format csr and user interface typically (on webpage) contains dropdown box with available key lengths. https://en.wikipedia.org/wiki/SPKAC

Keygen is (was) supported by firefox, chrome and opera, it has never been supported by internet explorer.

In case of opera12, after going through keygen form, but before receiving certificate, there used to be unattached private keys in certificate manager, which were generated for that csr. (and if final certificate never comes, those keys remains in certificate manager forever). (personal tab, in certificate manager).

I do not know exact details on how this is handled by firefox or chrome.

Answer 5

A CA issues digital certificates to entities and individuals after verifying their identity. It signs these certificates using its private key; its public key is made available to all interested parties in a self-signed CA certificate. CAs use this trusted root certificate to create a "chain of trust" -- many root certificates are embedded in Web browsers so they have built-in trust of those CAs. Web servers, email clients, smartphones and many other types of hardware and software also support PKI and contain trusted root certificates from the major CAs.

A typical PKI consists of hardware, software, policies and standards to manage the creation, administration, distribution and revocation of keys and digital certificates. Digital certificates are at the heart of PKI as they affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate.

A typical PKI includes the following key elements:

• A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities

• A registration authority, often called a subordinate CA, certified by a root CA to issue certificates for specific uses permitted by the root

• A certificate database, which stores certificate requests and issues and revokes certificates

• A certificate store, which resides on a local computer as a place to store issued certificates and private keys

Along with an entity’s or individual’s public key, digital certificates contain information about the algorithm used to create the signature, the person or entity identified, the digital signature of the CA that verified the subject data and issued the certificate, the purpose of the public key encryption, signature and certificate signing, as well as a date range during which the certificate can be considered valid.