7

$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.

5
+50

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.

  • If the browser did something (could very well have since it was pretty insistent on using Safari), could it have added that private key to my Keychain without me even being acknowledged? Otherwise it would have to be inside the .cer file but I'm not seeing any sign of a private key through the openssl options I've been successful with. – AndyC Mar 18 '16 at 3:29
  • @AndyC I've been looking to see if there's any API for Safari. However it's also possible you have an extension doing some of the work here. Usually there is a confirmation of sorts but it is usually "enroll for a certificate now" and then the private key is generated, stored and a CSR crafted. – diagprov Mar 18 '16 at 3:36
  • No extensions, I even made the request on a Windows PC, and then opened the approval link which downloaded the .cer file on my Mac Safari. – AndyC Mar 18 '16 at 3:38
  • I can't prove how (the background javascript) but I think you're correct, as I just went to a friend's enrollment link and checked Keychain immediately before importing the .cer file and I have a private key there - I suspect when I import the .cer file it will link up the public with that private key. – AndyC Mar 18 '16 at 4:07
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.

  • The openssl pkcs7 output just lists 3 certificates (no password needed) so I presumed that was all that was in it. The first certificate (subject=me) may contain other data but I can't seem to feed it into openssl pkcs12 to even verify, so guessing it's not the correct format. – AndyC Mar 18 '16 at 3:26
  • Doesn't seem to be in the (first) certificate addressed to me - it's exactly the same as the certificate in my Keychain. Given the size of those 3 certificates together, they're roughly the same as .cer file. I'm leaning towards browser-side key generation and adding it to Keychain without me even realising, in which case I doubt there is something for Linux – AndyC Mar 18 '16 at 4:03
  • PCKS#7 was intended for 'enveloped' and/or signed data with 'associated' certs and possibly CRLs, but today is mostly used for cert(s) with NO data; this is often labelled p7b or p7c. @AndyC for details of the first cert from a p7 openssl pkcs7 -print_certs -in p7file | openssl x509 -noout -text. To see any of the others you must break it (them) apart because one run of x509 handles only one cert; one way is ... | awk -vcmd='openssl x509 -noout -text' '{print|cmd}/-----END/{close(cmd)}' – dave_thompson_085 Mar 18 '16 at 15:55
1

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.

  • 2
    There is no visible private key nor is one generated by the user prior to receiving the certificate bundle and importing it into Keychain, hence the confusion. – AndyC Mar 15 '16 at 20:37
1

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.

0

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.

  • Thanks, but this doesn't explain where the private key in the user's Keychain (or in Windows in the Certificate store) came from or how it was generated. The end-user hasn't generated anything, yet when the certificate received from Symantec PKI is imported into the end-user's system/Keychain (or Windows Certificate store) there is a private key linked to the public key/cert. – AndyC Mar 18 '16 at 0:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.