Creating ECC Certificates Previously on Building an OpenSSL CA, we created a certificate revocation list, OCSP certificate, and updated our OpenSSL configuration file to include revokation URI data. Now we are ready to create our first server certificate and sign them with our fully armed and operational CA. What's becoming a theme there are two caveats to note prior to creating our first server CSR. Stop rolling your eyes and stay with me. Certificates MUST have subjectAltName (SAN) extensions of type DNSName defined1. Openssl currently supports population of SubjectAltName through configuration files only, including the current version v1.1.0f (true at guides publication date)2. Copy the Gist openssl_server.cnf file to /root/ca/intermediate/openssl_server.cnf and modify the contents for your own naming conventions. The openssl_server.cnf file has new entries at the [server_cert] location to create the subjectAltName field our certificate mentioned in the earlier noted points. This alternative name should match what we enter for the [commonName] field. [ server_cert ] subjectAltName = @alt_names [alt_names] DNS.0 = webby.grilledcheese.us You can add additional names to the certificate by iterating the [alt_names] section. Below is an example of the openssl config formatting for multiple names. Example: [alt_names] DNS.0 = yourdomain.com DNS.1 = sassymolassy.yourdomain.com DNS.2 = *.skeletor.yourdomain.com DNS.3 = *.orco.greyskull.yourdomain.com   RFC 5280 regarding subject alternative names states no upper bound limit is defined (no limit to how many names you can enter). However there are practical and application limitations so plan your certificate's alternate names wisely and try to match what you would implement in production. You're also thinking, how does this scale for multiple CSRs? It doesn't. You'll need to either update the openssl_server.cnf every time you want to create a new certificate or create a copy for each new certificate. We'll worry about scripting and simplifying that process in another followup article. Create the private key and CSR. Create the private key and CSR and specify either P-256 or P-384 approved curves. Since the root and intermediary CA's use P-384, Suite B allows us to use either. If we created the CA using P-256, we would not be able to use P-384 for the client/server certificate. We also need to ensure our certificate's hash function matches the signing CA, in our case SHA-384. # cd /root/ca # openssl req -config intermediate/openssl_server.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/webby.cheese.key.pem -out intermediate/csr/webby.cheese.csr Generating an EC private key writing new private key to 'intermediate/private/webby.cheese.key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Dev Lab]: Common Name []:webby.grilledcheese.us Email Address [[email protected]]: Create the Certificate Use the intermediary certificate to create and sign the CSR for webby.grilledcheese.us. # cd /root/ca # openssl ca -config intermediate/openssl_server.cnf -extensions server_cert -days 730 -in intermediate/csr/webby.cheese.csr -out intermediate/certs/webby.cheese.crt.pem Using configuration from intermediate/openssl_server.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: Check that the request matches the signature Signature ok