ECC based Client Certificate import in Chrome/Mozilla in windows

Question

I have deployed a PKI server and successfully able to generate the ECC based user or client certificates. but non of the web browser support ECC as public key. I have tried different tools and also trying to work this with MS CAPI through openssl but haven't get succeed.

Can some one recommend a utility for any of the web browser that can help to import the ECC based user certificate into its keystore?

or is there any library that can support this? here is the my certificate..

/ejbca/p12/pem#

openssl x509 -in testp256.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 5786377012642498827 (0x504d573c470ac90b)
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=ECCP-256, OU=admin, O=test
        Validity
            Not Before: Aug 23 13:32:42 2013 GMT
            Not After : Aug 23 13:32:42 2015 GMT
        Subject: CN=testp256
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:81:65:b4:c1:f4:95:7f:68:46:80:f2:42:5b:bf:
                    87:84:0a:98:42:3d:0a:e8:70:5c:e4:b3:4e:d7:29:
                    71:af:ce:c5:b3:fe:fd:02:2a:f3:bd:83:f7:50:23:
                    d1:75:af:dd:23:1f:be:62:a7:7a:d0:e2:be:03:c2:
                    e3:18:89:21:f4
                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                D7:27:DD:14:F1:42:0E:9C:E3:50:E1:D1:33:20:8A:53:DE:F2:14:14
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                keyid:EA:55:E0:24:6F:EA:9E:3C:63:FD:FF:AA:A6:DC:31:1F:F0:1C:FB:F7

            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, E-mail Protection
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:08:1b:44:e0:9b:ab:3c:9e:f6:e3:ef:28:d4:1e:
         cd:08:f4:1a:f5:21:c8:9f:e6:e0:6c:5e:7f:52:d0:47:a5:bf:
         02:21:00:ce:1a:58:57:f1:6b:82:5f:f2:72:af:ea:95:a3:05:
         02:ab:63:bf:13:fe:98:c2:0e:c2:a5:d3:d9:b9:74:77:6a

ECDSA is 100% supported with the public key as RSA. but the problem raised when you used public key as ECC. I have tested this with almost all of the web browsers — , Aug 23 '13 at 10:46
you can generate the certificates with Signing Algorithm as ECDSA and public key is RSA, it will work. that's how everyone is using in the web browsers. when you generate the certificates with public key as ECC and singing algo as ECDSA with NIST curves, web browsers doesn't accept that. its generated errors. — , Aug 23 '13 at 11:15
I am using EJBCA as PKI and i talk to their developers as well, they said. "Browser doesn't support full ECC based certificates only ECDSA with RSA is supported, you have to find some work around" — , Aug 23 '13 at 11:19
I've found a website [here](http://www.carbonwind.net/blog/post/2009/09/27/tlswoodgrovebankcom-meets-the-browsers.aspx) that seems to test TLS with ECC with Windows based browsers. — Maarten Bodewes, Aug 23 '13 at 11:36
my 1st priority is with web browser to work with ECC. the [link](http://www.carbonwind.net/blog/post/2009/09/27/tlswoodgrovebankcom-meets-the-browsers.aspx) which you provided is really awesome but i don't know how he get import this ECC based certificate. the one which i am using still generating the error's the error is "An internal Error occurred, either the user profile is not accessible or the private key that you are importing might required some cryptographic service provide" — , Aug 23 '13 at 12:21

score 4 · Answer 1 · answered Dec 26 '13 at 16:35

I have spent some time this morning to make some experiments on Firefox (version 26, for MacOS X), Safari (6.1.1, for MacOS X 10.7.5) and Chrome (31.0.1650.63, for MacOS X 10.7.5). Chrome and Safari both rely on MacOS's support for X.509 certificates, which is managed through KeyChain.

All my tests use EC keys from the P-256 curve, which (in the certificates) uses the "named curve" encoding. All certificates were generated with OpenSSL and match what you show. In particular, the extensions in your certificate are fine and work flawlessly in a RSA-based certificate.

What does not work

KeyChain refuses the import of any certificate which features an ECDSA public key; it returns an error "-67712" which maps to errSecInvalidKeyRef, aka "An invalid key was encountered.". See this reference page. Interestingly, KeyChain is supposed to be aware of the existence of ECDSA Keys since MacOS X 10.7, but this seems not to have percolated into full support for X.509 certificates containing ECDSA keys or signed with ECDSA.

Firefox uses its own cryptographic code called NSS. This includes X.509 support. Support for elliptic curve cryptography is new in NSS, and, more importantly, it is optional, so its presence depends on whether it was activated or not at build time. These messages indicate that at least RedHat still builds Firefox/NSS without ECC support.

In my tests, Firefox (the MacOS X version, obtained from the official source) accepts to try to import certificates with ECC, but with mixed results. A certificate signed with ECDSA will be somewhat broken; Firefox's GUI, when displaying the certificate, will claim that the certificate "cannot be verified for unknown reasons". Firefox will fail on the following:

Validating a server's certificate which has been signed with ECDSA.
Using a client's certificate which has been signed with ECDSA.
Using a client's certificate which contains an ECDSA key.

What works

Firefox, Safari and Chrome appear to be happy to connect to a SSL server whose private key is of ECDSA type. All three seem to require that the certificate has been signed with RSA (haven't tried for DSA), though. So the server itself may use elliptic curves and the cipher suite can be ECDHE-ECDSA-AES128-GCM-SHA256 (that's what Chrome used in that case), meaning that the key exchange was an elliptic curve based Diffie-Hellman, and the server half of that ECDH key exchange was signed by the server with its ECDSA private key. Chrome used TLS 1.2 (good !); Safari still uses TLS 1.0 (less good, but not too bad).

Replacing SHA-1 with SHA-256 or back changes nothing to all of this, so SHA-256 support seems, at last, to have reached completion.

OpenSSL supports EC keys in certificates, for certificate signatures, and for client and servers with no problem. In my tests, the server was OpenSSL with the s_server command-line option. openssl s_client connects to my server without any issue and can use an EC-based client certificate.

What might work

A custom build of Firefox with ECC support fully activated in NSS might work better. In any case, first try the P-256 curve (as you do) because most software that claim to "support ECC" actually support only two curves, P-256 and P-384 (because of the so-called "NSA Suite B cryptography"). Support for the 13 other NIST curves (from FIPS 186-4) is much more confidential; support for "generic curves" is a rarity (I never observed it in the wild).

Recent versions of Internet Explorer are supposed to be aware of ECDSA. Note that Windows has two internal frameworks for cryptography, CryptoAPI (the old one) and CNG. Only CNG supports EC keys, or, for that matter, SHA-256. CNG appears in Windows Server 2008 and Windows 7; up-to-date IE on these Windows versions should be able to use both certificates containing EC keys and certificates signed with ECDSA, both for client and server. At least so claims the documentation. Don't trust it until you have tested it, though.

Chrome on Windows will rely on Windows' abilities for X.509 certificates, so it is plausible that Chrome on Windows 7+ would be on par with IE's abilities on the same platform. There again, tests should be performed.

score 0 · Answer 2 · answered Sep 15 '13 at 19:06

Actually there was an issue with EJBCA and ECC PKCS#12 files. Encoding of keys in ECC can be done in two different ways, with "named curves" and with "explicit parameters". EJBCA used explicit parameters, but browsers only support named curves, and named curves is also with should be used according to RFC5915.

The encoding was changed for EJBCA 6.0.0, to be released later this autumn. You can find the issue in the EJBCA issue tracker here, https://jira.primekey.se/browse/ECA-3131. Tested with FireFox.

ECC based Client Certificate import in Chrome/Mozilla in windows

2 Answers2

What does not work

What works

What might work