How to use openssl ca with prime256v1?

Question

I am new to the encryption world, and reading about this, most websites say to use the prime256v1 for better performance and security.

After some days testing, finally I get my openssl CA structure working, almost steps come from this guide:

FreeBSD Certificate Authority

I did some changes, like search for OIDs (just adding same OIDs from permissions, example in CAs I have added 2.5.29.19, etc...)

Already have setup my CRL distribution points too, everything is working (at least seems to be working) nice.

The problem occurs if I change the final certificate structure from the guide, so for example, instead make a TLS Server Certificate using the following 3 steps from guide:

Generate PK

/usr/local/bin/openssl genpkey \
    -aes-256-cbc \
    -algorithm RSA \
    -pkeyopt 'rsa_keygen_bits:4096' \
    -out private/srv.example.org.key.enc \
    -pass file:private/srv.example.org.pwd

Generate Certificate Request

setenv SAN "DNS:srv.example.org"
/usr/local/bin/openssl req \
    -config etc/tls-server.conf \
    -new \
    -sha512 \
    -out certs/srv.example.org.csr \
    -key private/srv.example.org.key.enc \
    -subj /C=DE/ST=State/L=Locality/O=Example\ Corporation/OU=System\ Administration/CN=srv.example.org \
    -passin file:private/srv.example.org.pwd
unsetenv SAN

Sign the certificate

/usr/local/bin/openssl ca \
    -config etc/component-ca.conf \
    -batch \
    -md sha512 \
    -in certs/srv.example.org.csr \
    -out certs/srv.example.org.crt \
    -extensions server_ext \
    -startdate `date -j -u '+%Y%m01000000Z'` \
    -enddate `date -j -u -v+2y '+%Y%m01000000Z'` \
    -passin file:ca/component-ca/private/component-ca.pwd

For test an prime256v1, I have done:

Generate PK (testing prime256v1)

/usr/local/bin/openssl genpkey \
    ecparam \
    -name prime256v1 \
    -genkey \
    -param_enc explicit \
    -out private/srv.example.org.key \

Generate Certificate Request (testing prime256v1)

setenv SAN "DNS:srv.example.org"
/usr/local/bin/openssl req \
    -new \
    -sha512 \
    -config etc/tls-server.conf \
    -key private/srv.example.org.key.enc \
    -nodes \
    -out certs/srv.example.org.csr \
    -subj /C=DE/ST=State/L=Locality/O=Example\ Corporation/OU=System\ Administration/CN=srv.example.org \
unsetenv SAN

Sign the certificate (testing prime256v1)

/usr/local/bin/openssl ca \
    -config etc/component-ca.conf \
    -batch \
    -md sha512 \
    -in certs/srv.example.org.csr \
    -out certs/srv.example.org.crt \
    -extensions server_ext \
    -startdate `date -j -u '+%Y%m01000000Z'` \
    -enddate `date -j -u -v+2y '+%Y%m01000000Z'` \
    -passin file:ca/component-ca/private/component-ca.pwd

The certificate is signed without errors...

When I try to access my domain browsers block the access saying the error:

No Cypher Overlap

My first guess is because the mix of encryption, then I have changed entire commands from the guide to make Root-CA, Network-CA, Component-CA all using secp521r1, since it seems to be a good security practice use highest encryption on top and low encryption (prime256v1) on bottom for make compatibility...

And then, same error occurs:

No Cypher Overlap

So if I wish to use prime256v1 I need to make all structure with only it? If tomorrow this process becomes weak, I need to remake the entire CA with new security encryption (eg, secp384r1)?

On Server side I have used the Mozilla SSL Configuration Generator to setup:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSL

CipherSuite
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

PS.: I have no plans to purchase an online SSL Validated Certificate, but I will love to have a working CA testing structure working for study.

This is probably a configuration issue with your (unknown) server. When you try to use ECC key in a certificate you need to have ECDSA ciphers enabled at the server. — Steffen Ullrich, May 09 '16 at 04:49
I have tested using on apache: SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL and SSLProtocol all I get an new error: SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT — Wisdom, May 11 '16 at 06:27
Unfortunately these are all just information snippets which reflect different stages of your tests. It is impossible to rebuild your problem based on these information. I recommend that you look into the server log files for more information. If this does not help please provide a minimal but working setup so that others can exactly reproduce your problem. — Steffen Ullrich, May 11 '16 at 09:17
Thanks for the reply Steffen, would you be more specific about what to search in logs? I already have tried look inside and dont found any info, maybe I need use an specific log format. The exact setup is the one from the guide, the only change is the cipher suite from Mozzila SSL Configuration Generator and the Certified Sign request, changing from usually RSA to prime256v1, testing on SSL Labs says is ok, but the page never load, still blank ever. On RSA setup there an extra setup for remove encryption of the Key, I haven't did it on prime256v1 because not found in guides info to it. — Wisdom, May 14 '16 at 13:29
Note: is blank screen after change ciphers and protocols to +ALL, testing this way because your hint. — Wisdom, May 14 '16 at 13:31
Could you try a simpler way to create your certificate as seen in http://stackoverflow.com/questions/11992036/how-do-i-create-an-ecdsa-certificate-with-the-openssl-command-line. This way one can maybe find out if it is more a problem with the server configuration or with your certificate and key. As for the log files: look if there are information in the error log, not the access log. And as for removing the password from the EC key: `openssl ec` should help you the same way as `openssl rsa` does help you to remove the password from the RSA key. — Steffen Ullrich, May 14 '16 at 14:29

score 1 · Answer 1 · edited Oct 07 '21 at 08:14

Probably useless, but since this got necroed ...

I don't believe the Q is accurate, because

/usr/local/bin/openssl genpkey \
    ecparam \
    [anything]

is an error and cannot have worked. But if you actually did

/any/openssl ecparam -name prime256v1 -genkey -param_enc explicit -out keyfile

and used that key for a CSR and cert as described, you may have created an unusable cert.

When RFC 4492 (first) defined ECC options for TLS in 2006, it followed then-current X9.62 practice to allow both predefined (standardized) curves, also called 'named' and identified in TLS by registered numbers, and 'arbitrary explicit' curves (over prime or characteristic-two fields) that might be defined by users. In practice people implemented only 'named' curves -- and often only a subset of them, such as the ones adopted/approved by NIST in FIPS 186-2 and especially the two selected by NSA's then-fashionable 'Suite B', which are called secp256r1 secp384r1 in SEC1 or P-256 P-384 in FIPS 186, and the first prime256v1 in X9.62. Almost nobody generated their own Weierstrass curves, and the few that did got them registered e.g. Brainpool RFC7027. (Note that the schemes for Bernstein et al's 25519 and 448 are not just different curves but different algorithms; they don't fit in the original 4492/X9.62 definition at all.)

Consistent with this OpenSSL didn't implement 'arbitrary' curves in TLS -- although it does implement ECC primitive operations using X9.62 formats. I don't know any other TLS implementation that does implement arbitrary curves for TLS, and the standards have moved away from it. For PKIX certificates (related to but distinct from TLS) RFC3279 in 2002 supported EC pubkeys using explicit parameters (in painful detail) or 'namedCurve', but RFC5480 in 2009 prohibits explicit (now 'specified') parameters and requires namedCurve only. Post-Q, RFC8422 in 2018 modifies RFC4492 (for TLS1.0-1.2) to reduce the list of named curves and remove (deprecate) the 'arbitrary' option; concurrently RFC8446 for TLS1.3 adopted the same reduced list of named curves, plus predefined/registered non-EC groups (called Finite Field groups) from RFC7919 in 2016, and no arbitrary groups ever.

Using -param_enc explicit discards the information that this key is on a standardized curve and makes it appear arbitrary. (edit) As a result OpenSSL for a long time did not treat it as matching a ClientHello offer to use P-256; it would match a client offer to use 'explicit_prime', but OpenSSL doesn't implement that, and I've not seen any (other) implementation that offers it anyway. Thus an OpenSSL-based server couldn't agree any ECC-based ciphersuite because the cert isn't suitable, nor any other authenticated ciphersuite because you haven't provided any other cert, and it can't agree a non-authenticated ciphersuite because those are disabled because they're insecure, so you get 'no common cipher' (or whatever other wording is used for alert 40). However, I didn't notice (or re-check) when I wrote this but OpenSSL 1.1.0l and 1.1.1d up (since 2 months earlier) recognize explicit parameters which are actually for a supported named curve, and convert them back to the named version, so this works. However, explicit still wastes space and violates 5480, and might or might not interoperate successfully, so I recommend against it.

TLDR: don't use -param_enc explicit

How to use openssl ca with prime256v1?

1 Answers1