Building an OpenSSL Certificate Authority - Creating Your Root Certificate
Creating Your Root Certificate Authority In our previous article, Introductions and Design Considerations for Eliptical Curveswe covered the design requirements to create a two-tier ECC certificate authority based on NSA Suite B's PKI requirements. We can now begin creating our CA's root configuration. Creating the root CArequires us to generate a certificate and private key,since this is the first certificate we're creating, it will be self-signed. The root CA will not sign client and server certificates, it's job it only to create intermeidary certificates and act as the root of our chain of trust. This is standard practice across the public and private PKI configurations and so too should your lab environments. Create Your Directory Structure Create a directory to store your root CA pair and config files. # sudo bash # mkdir /root/ca Yep, I did that. This is for a test lab and permissions may not match real world requirements. I sudoed into bash and created everything under root; aka playing with fire. This affects ownership down the line if you chmod private key files and directoriesto user access only so determine for yourself what user/permission will be accessing files for certificate creation. I have a small team and trust them with root within a lab environment (snapshots allow me to be this trusting). Create your CA database to keep track of signed certificates # cd /root/ca # mkdir private certs crl # touch index.txt # echo 1000 > serial We begin by creating a working root directory with sub directories for the various files we'll be creating. This will allow you to apply your preferred security practices should you choose to do so. Since this is a test lab and I am operating as root, I won't be chmod'ing anything today. Create Your OpenSSL Config File OpenSSLuses configuration files to simplify/template the components of a certificate. Copy the GIST openssl_root.cnf file to /root/ca/openssl_root.cnf which is already prepared for this demo. For the root CA certificate creation, the [ CA ] section is required and will gather it's configuration from the [ CA_default ] section. [ ca ] # `man ca` default_ca = CA_default The [CA_default] section in the openssl_root.cnf file contains the variables OpenSSL will use for the root CA. If you're using alternate directory names from this demo, update the file accordingly. Note the long values for default days (10 years) as we don't care about renewing the root certificate anytime soon. [ CA_default ] # Directory and file locations. dir = /root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/certs database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # The root key and root certificate. private_key = $dir/private/ca.cheese.key.pem certificate = $dir/certs/ca.cheese.crt.pem # For certificate revocation lists. crlnumber = $dir/crlnumber crl = $dir/crl/ca.cheese.crl.pem crl_extensions = crl_ext default_crl_days = 3650 # SHA-1 is deprecated, so use SHA-2 or SHA-3 instead. default_md = sha384 name_opt = ca_default cert_opt = ca_default default_days = 3650 preserve = no policy = policy_strict For the root CA, we define [policy_strict] which will later force the intermediary's certificateto match country, state/province, and organization name fields. [ policy_strict ] The root CA should only sign intermediate certificates that match. # See POLICY FORMAT section of `man ca`. countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional The [ req ] section is used for OpenSSL certificate requests. Some of the values listed will not be used since we are manually specifying them during certificate creation. [ req ] # Options for the `req` tool (`man req`). default_bits = 4096 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, please use SHA-2 or greater instead. default_md = sha384 # Extension to add when the -x509 option is used. x509_extensions = v3_ca I pre-populate the [ req_distinguished_name ] section with values I'll commonly used to save typing down the road. [ req_distinguished_name ] countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address # Optionally, specify some defaults. countryName_default = US stateOrProvinceName_default = WA localityName_default = Seattle 0.organizationName_default = Grilled Cheese Inc. organizationalUnitName_default = Grilled Cheese Root CA emailAddress_default = grilledcheese@yummyinmytummy.us The [ v3_ca ] section will further define the Suite B PKI requirements, namely basicConstraints and acceptable keyUsage values for a CA certificate. This section will be used for creating the root CA's certificate. [ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign Selecting the Suite B compliant elliptical curve We're creating a Suite B infrastructure so we'll need to pick an acceptable curve following P-256 or P-384. To do this, run the following OpenSSLcommand: openssl ecparam -list_curves This will give you a long list of options but which one to pick? Let's isolate the suites within the 256 & 384 prime fields; we can grep the results for easier curve identification. openssl ecparam -list_curves | grep '256\|384' And we get the following results (your results may vary depending on the version of OpenSSL running): # openssl ecparam -list_curves | grep '256\|384' secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field brainpoolP256r1: RFC 5639 curve over a 256 bit prime field brainpoolP256t1: RFC 5639 curve over a 256 bit prime field brainpoolP384r1: RFC 5639 curve over a 384 bit prime field brainpoolP384t1: RFC 5639 curve over a 384 bit prime field I am going to use secp384r1 as my curve of choice. It's good to mention that RFC5480 notes secp256r1 (not listed) is referred to as prime256v1 for this output's purpose. Why not use something larger than 384? Thank Google. People absolutely were using secp521r1 then Google dropped support for it (read Chromium Bug 478225 for more). The theoryis since NSA Suite B PKI did not explicitly call out anything besides 256 or 384, the Chromium team quietly decided it wasn't needed and dropped support for it. Yea... it kinda annoyed a few people. So to avoid future browser issues, we're sticking with what's defined in public standards. Create the Root CA's Private Key Using the names defined in the openssl_root.cnf's private_key value and our selected secp384r1 ECC curve we will create and encrypt the root certificates private key. # openssl ecparam -genkey -name secp384r1 | openssl ec -aes256 -out private/ca.cheese.key.pem read EC key writing EC key Enter PEM pass phrase: ****** Verifying - Enter PEM pass phrase: ****** Note:The ecparam function within OpenSSL does not encrypt the private key like genrsa/gendsa/gendh does. Instead we combined the private key creation (openssl ecparam) with a secondary encryption command (openssl ec) to encrypt private key before it is written to disk. Keep the password safe. Create the Root CA's Certificate Using the new private key, we can now generate our root'sself-signed certificate. We do this because the root has no authority above it to request trust authority from;it is the absolute source of authority in our certificate chain. # openssl req -config openssl_root.cnf -new -x509 -sha384 -extensions v3_ca -key private/ca.cheese.key.pem -out certs/ca.cheese.crt.pem Enter pass phrase for private/ca.cheese.key.pem: ****** 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 Root CA]: Common Name []:Grilled Cheese Root Certificate Authority Email Address [grilledcheese@yummyinmytummy.us]: Using OpenSSL we can validate the Certificate contents to ensure we're following the NSA Suite B requirements. # openssl x509 -noout -text -in certs/ca.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: ff:bd:f5:2f:c5:0d:3d:02 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Aug 22 23:53:05 2017 GMT Not After : Aug 20 23:53:05 2027 GMT Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:a6:b7:eb:8b:9f:fc:95:03:02:20:ea:64:7f:13: ea:b7:75:9b:cd:5e:43:ca:19:70:17:e2:0a:26:79: 0a:23:2f:20:de:02:2d:7c:8f:62:6b:74:7d:82:fe: 04:08:38:77:b7:8c:e0:e4:2b:27:0f:47:01:64:38: cb:15:a8:71:43:b2:d9:ff:ea:0e:d1:c8:f4:8f:99: d3:8e:2b:c1:90:d6:77:ab:0b:31:dd:78:d3:ce:96: b1:a0:c0:1c:b0:31:39 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:77:a1:f9:e2:ab:3a:5a:4b:ce:8d:6a:2e:30:3f: 01:cf:8e:76:dd:f6:1f:03:d9:b3:5c:a1:3d:6d:36:04:fb:01: f7:33:27:03:85:de:24:56:17:c9:1a:e4:3b:35:c4:a8:02:31: 00:cd:0e:6c:e0:d5:26:d3:fb:88:56:fa:67:9f:e9:be:b4:8f: 94:1c:2c:b7:74:19:ce:ec:15:d2:fe:48:93:0a:5f:ff:eb:b2: d3:ae:5a:68:87:dc:c9:2c:54:8d:04:68:7f Reviewing the above we can verify the certificate details: The Suite B Signature Algorithm: ecdsa-with-SHA384 The certificate date validity when we specificed -days 3650: Not Before: Aug 22 23:53:05 2017 GMT Not After : Aug 20 23:53:05 2027 GMT The Public-Key bit length: (384 bit) The Issuer we defined in the openssl_root.cnf: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The Certificate Subject, since this is self-signed, refers back to itself: Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The eliptical curve used when we created the private key: NIST CURVE: P-384 Verify the X.509 v3 extensions we defined within the openssl_root.cnf for a Suite B CA use: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign The root certificate and private key are now compete and we have the first part of our CA complete. Step 1 complete! In our next article we willcreate the intermediary certificate to complete the chain of trust in our two-tier hierarchy.Building an OpenSSL Certificate Authority - Configuring CRL and OCSP
Certificate Revocation Lists We completed reviewing our PKI design considerations and createdroot and intermediary certificates completeing our two-tier certificate authority. Now we'll createcertificate revocation configurations to comply withNSA Suite B PKI. A certificate revocation list (CRL) is a published list of revoked certificates issued and updated by the certificate authority who signed them. Clients like your internet browser, will check the certificate's CRL URI to find out if the certificate is valid. When a certificate is revoked, the CRL is updated to reflect the revokation and published accordingly. Lists are not the most efficient way to maintain a record of revocation in high volume scenarios so some application vendors have deprecated their use in favor of online certificate status protcol (OCSP). We still needa CRL configuraiton as it's still common and recommended for backward compatibility. Previously we created a CRL URI via the openssl_intermediary.cnf when creating the intermediary certificate. This was an exercise in anticipation of us creating the CRL. Don't forgetwe're adhering to NSA's Suite B PKI so we have to remember: Every Suite B certificate and CRL MUST be signed using ECDSA And certificate and CRL MUST be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key The OpenSSL configuration file object [ server_cert ] includes crlDistributionPoints = @crl_info which directs the OpenSSL to: [crl_info] URI.0 = http://crl.grilledcheese.us/whomovedmycheese.crl This allows us to enter multiple CRL distribution points for redundancy. Create the CRL # cd /root/ca # openssl ca -config intermediate/openssl_intermediate.cnf -gencrl -out intermediate/crl/whomovedmycheese.crl Using configuration from intermediate/openssl_intermediate.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: ****** Validate the CRL with OpenSSL # openssl crl -in intermediate/crl/whomovedmycheese.crl -noout -text Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: ecdsa-with-SHA384 Issuer: /C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us Last Update: Aug 24 23:21:38 2017 GMT Next Update: Feb 20 23:21:38 2018 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 CRL Number: 4097 No Revoked Certificates. Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:7b:e4:08:01:06:60:c8:e8:c8:fb:a7:e8:49:7b: bf:ee:a6:a6:19:8f:93:67:6c:15:25:bb:c0:d2:ad:c1:ff:05: d4:73:e0:72:f0:35:cd:64:35:8b:83:e7:7c:47:ed:ea:02:31: 00:d4:3c:30:7c:00:73:b6:93:34:3e:1d:96:8f:ba:8a:9b:21: 3e:ff:36:95:2c:e9:6e:e9:4b:9c:6c:49:1d:fd:ba:6a:75:70: 41:a5:5e:67:4d:ca:04:2c:c5:37:46:52:91 Yesit was that easy. The CRL file will reside at the URI you specified within the openssl_intermediary.cnf . Online Certificate Status Protocol The online certificate status protocol (OCSP) is used to check x.509 certificates revocation status. This is the preferred method over CRL by utilizing OCSP responders to return a positive, negative, or unknown status. This provides a faster response for the revocation check versus parsing potentially bulky CRL files. The OCSP responder must be signed by the same CA that issued the certificate being validated. OCSP stapling further improves certificate revocation checking by allowing the server hosting the certificate in question to provide a time-stamped response on behalf of the OCSP responder. Additions to the x.509 v3 extensions would require an OCSP stapled response during TLS negotiation or the connection would be terminated (unless an unknownstatus or no response is returned). Setting up an OCSP responder equires a server with our OCSP certificate in play and is out of scope for this article. OCSP configuration data is already present in our /root/ca/intermediate/openssl_intermediate.cnf so when the intermediary certificate was created, it referenced theconfiguration through the [ v3_intermediate_ca ] extension authorityInfoAccess = @ocsp_info. [ocsp_info] caIssuers;URI.0 = http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP;URI.0 = http://ocsp.grilledcheese.us/ Create the OCSP key & certificate Just like the intermediary CA, we'll generate the key and CSR in one line, using the same secp384r1 elliptical curve during root and intermediary CA creation. # cd /root/ca # openssl req -config intermediate/openssl_server.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/ocsp.cheese.key.pem -out intermediate/csr/ocsp.cheese.csr.pem -extensions server_cert Generating an EC private key writing new private key to 'intermediate/private/ocsp.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 Intermediary CA]: Common Name []:ocsp.grilledcheese.us Email Address [grilledcheese@yummyinmytummy.us]: Sign the CSR with our Intermediary Certificate Authority # openssl ca -config intermediate/openssl_intermediate.cnf -extensions ocsp -days 365 -notext -md sha384 -in intermediate/csr/ocsp.cheese.csr.pem -out intermediate/certs/ocsp.cheese.crt.pem Using configuration from intermediate/openssl_intermediate.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4103 (0x1007) Validity Not Before: Aug 28 22:23:14 2017 GMT Not After : Aug 28 22:23:14 2018 GMT Subject: countryName = US stateOrProvinceName = WA localityName = Seattle organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Intermediary CA commonName = ocsp.grilledcheese.us emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 55:96:45:08:3E:BA:6A:F7:1C:A2:5A:4E:5C:BB:63:65:44:8F:DD:4B X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing Certificate is to be certified until Aug 28 22:23:14 2018 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Verify the certificate's usage is set for OCSP # openssl x509 -noout -text -in intermediate/certs/ocsp.cheese.crt.pem X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing OCSP Stapling and Beyond OpenSSLdoes support operating as an OCSP responder. Per OpenSSL's OCSP man page, running their OCSP server is benefitial for test and demo purposes and is not recommended forproduction OCSP responder use. Other PKI vendors have more robust OCSP management capabilitiesintegratinginto CMS web solutions. Since most clients carry on with a certificates duty if OCSP is unavailablethis shouldn't concern us for testing purposes. If you want to setup OCSP stapling DevCentral's Jason Rahm has a guide on setting up OCSP Stapling for use within the virtual server interfaces if you're so inclined to enable BIG-IP for these features. Now we've completed a basic CRL and OCSP configuration, our clients (web browsers) shouldn't complain and we can move on to the fun part, creating server certificates!
Use F5 LTM as HTTP Proxy
Problem this snippet solves: LTM product can be used as a HTTP Proxy for servers and PC. This code explains minimum requirements to configure proxy feature without SWG module (configurations from Explicit Forward Proxy documentation without documentation ) and without explicit proxy iApp. How to use this snippet: All these commands must be run in bash shell. Create HTTP PROXY VIRTUAL SERVER Configure variables used in next commands Variable HTTPBaseName is used to create : Resolver object : RESOLVER_${HTTPBaseName} HTTP profile : http_${HTTPBaseName} virtual server : VS_${HTTPBaseName} HTTPBaseName="HTTP_FORWARD_PROXY" VS_IP="192.168.2.80" VS_PORT="8080" create DNS resolver with your DNS server (1.1.1.1 is for demo using cloudflare) tmsh create net dns-resolver RESOLVER_${HTTPBaseName} { forward-zones replace-all-with { . { nameservers replace-all-with { 1.1.1.1:domain { } } } } route-domain 0 } create HTTP profile type explicit, using DNS resolver. The parameter default-connect-handling allow enables HTTPS connections without SSL inspection tmsh create ltm profile http http_${HTTPBaseName} { defaults-from http-explicit explicit-proxy { default-connect-handling allow dns-resolver RESOLVER_${HTTPBaseName} } proxy-type explicit } create HTTP proxy Virtual server tmsh create ltm virtual VS_${HTTPBaseName} { destination ${VS_IP}:${VS_PORT} ip-protocol tcp mask 255.255.255.255 profiles replace-all-with { http_${HTTPBaseName} { } tcp } source 0.0.0.0/0 source-address-translation { type automap } translate-address enabled translate-port enabled} ENABLE SSL FORWARD PROXY This section is not required to forward HTTPS requests but only to enable SSL inspection on HTTPS requests. Note : Following configuration requires SSL, Forward Proxy License. Configure variables used in next commands Variable SSLBaseName is used to create : certificate / key pair : ${SSLBaseName} Client SSL profile : clientssl_${SSLBaseName} Server SSL profile : serverssl_${SSLBaseName} virtual server : VS_${SSLBaseName} SSLBaseName="SSL_FORWARD_PROXY" dirname="/var/tmp" CASubject="/C=FR/O=DEMO\ COMPANY/CN=SSL\ FORWARD\ PROXY\ CA" Create self-signed certificate for CA purpose (not available in WebUI) Self-signed certificates created in WebUI doesn't have CA capability required for SSL FORWARD PROXY. openssl genrsa -out ${dirname}/${SSLBaseName}.key 4094 openssl req -sha512 -new -x509 -days 3650 -key ${dirname}/${SSLBaseName}.key -out ${dirname}/${SSLBaseName}.crt -subj "${CASubject}" Import certificates in TMOS tmsh install sys crypto key ${SSLBaseName}.key from-local-file ${dirname}/${SSLBaseName}.key; tmsh install sys crypto cert ${SSLBaseName}.crt from-local-file ${dirname}/${SSLBaseName}.crt; After CA Certificate is imported, browse in WebUI, retrieve it and import it in client browsers trusted CA Create SSL profiles for SSL FORWARD PROXY tmsh create ltm profile client-ssl clientssl_${SSLBaseName} { cert-lookup-by-ipaddr-port disabled defaults-from clientssl mode enabled proxy-ca-cert ${SSLBaseName}.crt proxy-ca-key ${SSLBaseName}.key ssl-forward-proxy enabled } tmsh create ltm profile server-ssl serverssl_${SSLBaseName} { defaults-from serverssl ssl-forward-proxy enabled } create SSL FORWARD PROXY Virtual server tmsh create ltm virtual VS_${SSLBaseName} { destination 0.0.0.0:https ip-protocol tcp profiles replace-all-with { clientssl_${SSLBaseName} { context clientside } serverssl_${SSLBaseName} { context serverside } http { } tcp { } } source 0.0.0.0/0 translate-address disabled translate-port disabled vlans replace-all-with { http-tunnel } vlans-enabled } Change HTTP EXPLICIT PROXY Default Connect Handling to Deny tmsh modify ltm profile http http_${HTTPBaseName} explicit-proxy { default-connect-handling deny } Note : These commands were tested in both 12.1 and 13.1 versions. Code : No CodeBuilding an OpenSSL Certificate Authority - Creating Your Intermediary Certificate
Creating Your Intermediary Certificate Authority Previously we created the first part of our OpenSSL CA by building our root certificate. We are now ready to complete our CA chain by creating and signing the intermediary certificate.The intermediary will beresponsible for signing client and server certificate requests. It acts as an authoritative proxy for the root certificate hence the name intermediary. The chain of trust will extend from the root certificate to the intermediary certificate down to the certificates you'll deploy within your infrastructure. Create your directory structure Create a new subdirectory under /root/ca to segregate intermediary files our root configuration . # sudo bash # mkdir /root/ca/intermediate We're creating the same directory structure previously used under /root/ca within /root/ca/intermediary . It's your decision if you if you want to do something different. Some of my best friends are flat directory structures and we don't judge personal practices. Create your intermediary CA database to keep track of signed certificates # cd /root/ca/intermediate # mkdir certs crl csr private # touch index.txt # echo 1000 > serial Create a crlnumber file for the intermediary CA to use # echo 1000 > /root/ca/intermediate/crlnumber Similar to the earlier serial statement, this will create the crlnumber file and start the numerical iteration at 1000. This will be used for future certificate revocation needs. Create your OpenSSL intermediary config file Copy the GIST openssl_intermediate.cnf file to /root/ca/intermediate/openssl_intermediate.cnf and modify the contents for your own naming conventions. Similar to the root_ca.cnf , the [CA] is required and will gather it's configuration from the [CA_default] section. Changes to the [int_ca] include: [ CA_default ] # Directory and file locations. dir = /root/ca/intermediate private_key = $dir/private/int.cheese.key.pem certificate = $dir/cers/int.cheese.crt.pem crlnumber = $dir/crlnumber crl = $dir/crl/int.cheese.crl.pem crl_extensions = crl_ext policy = policy_loose We have new certificate names for our intermediary use and define policy_loose so future certificate requests don't have to match country, state/province, or organization. Create the Intermediary's Private Key and Certificate Signing Request Similar to the root certificate, we're following the NSA Suite B requirements and matching the root's elliptical curve, secp384r1. We'll alsocreate the CSR and private key all in one line, making your scripts and life a bit easier. # cd /root/ca # openssl req -config intermediate/openssl_intermediate.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/int.cheese.key.pem -out intermediate/csr/int.cheese.csr Generating an EC private key writing new private key to 'intermediate/private/int.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 Intermediary CA]: Common Name []:Grilled Cheese Inc. Intermediary Certificate Authority Email Address [grilledcheese@yummyinmytummy.us]: Sign the certificate request with the root certificate and use the openssl_intermediate.cnf config file to specify the [v3_intermediate_ca] extension instead of the [v3_ca] as we did for the root. The openssl_intermediate.cnf has a few changes which we need to note. [ v3_intermediate_ca ] # Extensions for a typical intermediate CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign crlDistributionPoints = @crl_info authorityInfoAccess = @ocsp_info [crl_info] URI.0 = http://crl.grilledcheese.us/whoremovedmycheese.crl [ocsp_info] caIssuers;URI.0 = http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP;URI.0 = http://ocsp.grilledcheese.us/ The Certificate Revocation List (crl) and Online Certificate Status Protocol (OCSP) should be included within the intermediary certificate. This lets systems know where check and see if the intermediary certificate was revoked by the root at any given time. We will cover this in detail later and browsers do not necessarily check the intermediary certificates for revocation, but they absolutely do for the site certificates. We're adding CRL and OCSP to the Intermediary CA for best practices purpose. Create the intermediate certificate Sign the csr/int.cheese.cs r with the root's certificate. We are going to drop down to /root/ca so the creation of the intermediary certificate is stored within the root's index.txt and we'll also use the root's OpenSSL Config file openssl_root.cnf . # openssl ca -config openssl_root.cnf -extensions v3_intermediate_ca -days 3600 -md sha384 -in intermediate/csr/int.cheese.csr -out intermediate/certs/int.cheese.crt.pem Using configuration from openssl_root.cnf Enter pass phrase for /root/ca/private/ca.cheese.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4097 (0x1001) Validity Not Before: Aug 24 21:51:07 2017 GMT Not After : Jul 3 21:51:07 2027 GMT Subject: countryName = US stateOrProvinceName = WA organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Intermediary CA commonName = Grilled Cheese Inc. Intermediary Certificate Authority emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Subject Key Identifier: 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Certificate is to be certified until Jul 3 21:51:07 2027 GMT (3600 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Validate the Certificate Contents with OpenSSL. # openssl x509 -noout -text -in intermediate/certs/int.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: 4097 (0x1001) Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Aug 24 21:51:07 2017 GMT Not After : Jul 3 21:51:07 2027 GMT Subject: C = US, ST = WA, O = Grilled Cheese Inc., OU = Grilled Cheese Intermediary CA, CN = Grilled Cheese Inc. Intermediary Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:9b:14:9a:55:6d:db:15:7f:d7:8b:fd:37:4d:ba: e8:50:8e:88:32:99:27:4e:20:36:25:8b:7b:ac:bb: 2f:d6:61:c1:5a:c8:e6:4c:98:20:3f:cf:86:3c:bf: f4:f3:b0:1c:1c:0b:cc:7f:e4:4b:13:59:58:a1:53: 87:cb:4c:17:66:04:21:01:6a:44:5f:22:31:7d:3d: fe:a2:e7:73:c8:77:7c:1a:f9:9c:4a:9d:e7:77:6a: c7:9e:3e:f0:4a:b0:37 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:74:07:ba:fe:4b:71:78:d8:d2:7f:84:c0:50:b4: b6:df:6c:f6:57:f5:d9:2c:4b:e1:d4:d8:1d:78:fd:7e:bf:0a: 81:86:bb:40:c5:9b:97:6f:83:04:5f:d3:85:36:6c:d6:02:31: 00:d3:08:78:1c:da:6d:ef:1d:bb:27:df:0b:76:eb:ab:84:b2: 91:04:25:1a:85:5b:d5:c3:cd:66:e4:9e:14:b2:c0:ed:9c:59: b7:18:c3:26:eb:df:78:13:68:47:66:b5:43 Similar to the root, we can note the usage and algorithms but we have the addition of: * X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl *Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Create the certificate chain The root certificate and intermediary certificate must be available to the requesting client/server in order to validate the chain of trust. To complete the trust validation, a certificate chain must be available to the client application. A certificate chain usually takes the form of separate certificates installed into Root and Intermediary containers (as the case for Windows), or bundled together either in a .pfx cert and certchain bundle or a PEM formatted text file. Concatenate the root and intermediate certificates together to create a PEM certificate chain text file. # cd /root/ca # $cat intermediate/certs/int.cheese.crt.pem certs/ca.cheese.crt.pem > intermediate/certs/chain.cheese.crt.pem The file should look similar to this with two separate BEGIN and END statements for each certificate (example condensed for space): # cat intermediate/certs/chain.cheese.crt.pem -----BEGIN CERTIFICATE----- MIID/TCCA4OgAwIBAgICEAEwCgYIKoZIzj0EAwMwgdQxCzAJBgNVBAYTAlVTMQsw CQYDVQQIDAJXQTEQMA4GA1UEBwwHU2VhdHRsZTEcMBoGA1UECgwTR3JpbGxlZCBD ...... hkjOPQQDAwNoADBlAjB0B7r+S3F42NJ/hMBQtLbfbPZX9dksS+HU2B14/X6/CoGG u0DFm5dvgwRf04U2bNYCMQDTCHgc2m3vHbsn3wt266uEspEEJRqFW9XDzWbknhSy wO2cWbcYwybr33gTaEdmtUM= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDQTCCAsegAwIBAgIJAP+99S/FDT0CMAoGCCqGSM49BAMDMIHUMQswCQYDVQQG EwJVUzELMAkGA1UECAwCV0ExEDAOBgNVBAcMB1NlYXR0bGUxHDAaBgNVBAoME0dy ...... CgYIKoZIzj0EAwMDaAAwZQIwd6H54qs6WkvOjWouMD8Bz4523fYfA9mzXKE9bTYE +wH3MycDhd4kVhfJGuQ7NcSoAjEAzQ5s4NUm0/uIVvpnn+m+tI+UHCy3dBnO7BXS /kiTCl//67LTrlpoh9zJLFSNBGh/ -----END CERTIFICATE----- Note: In the real world hosting application should never have the entire chain available as it defeats a core principle of PKI. It's recommended in test labs to distribute the root certificate to all testing client applications and systems and include only the intermediary along with the server certificate. This way the client can establish the trust between the intermediary and root certificates. Next we'll move on to creating our CLR endpoint list and OCSP certificate. Our intermediary certificate is now created and signed and we are ready to move on. To complete the CAour next articlewe will create our certificate revocation list (CRL) endpointand online certificate status protocol (OCSP) certificate allowing us to revoke certificates. Lab environments rarely need revocation functionalitybut modern clients check for CLR and OCSP URIs so it's nessisary to have the configruation defined at minimum. Let's proceed.Building an OpenSSL Certificate Authority - Creating ECC Certificates
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 themethere 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 defined 1 . 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 matchwhat 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 5280regarding 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 [grilledcheese@yummyinmytummy.us]: 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 Certificate Details: Serial Number: 4104 (0x1008) Validity Not Before: Sep 6 20:10:39 2017 GMT Not After : Sep 6 20:10:39 2019 GMT Subject: countryName = US stateOrProvinceName = WA localityName = Seattle organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Dev Lab commonName = webby.grilledcheese.us emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: Grilled Cheese Generated Server Certificate X509v3 Subject Key Identifier: E0:48:57:7E:F9:92:BA:B9:F9:23:41:8D:3D:85:86:82:25:5C:FC:92 X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD DirName:/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us serial:10:01 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ X509v3 Subject Alternative Name: DNS:webby.grilledcheese.us Certificate is to be certified until Sep 6 20:10:39 2019 GMT (730 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Validate the certificate # openssl x509 -noout -text -in intermediate/certs/webby.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: 4104 (0x1008) Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, O = Grilled Cheese Inc., OU = Grilled Cheese Intermediary CA, CN = Grilled Cheese Inc. Intermediary Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Sep 6 20:10:39 2017 GMT Not After : Sep 6 20:10:39 2019 GMT Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Dev Lab, CN = webby.grilledcheese.us, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:bf:48:5b:9b:b2:e2:cf:de:e6:5a:33:3a:9f:73: 70:82:75:86:bd:6f:6a:98:e6:5e:31:fb:af:c5:9f: 68:dc:8b:bc:24:69:08:d8:35:c9:be:76:d4:3d:c5: 48:b3:8f:f6:fd:4a:b9:75:70:58:2c:65:f5:72:61: 62:b8:58:ae:ba:f1:cc:95:1e:bd:60:b2:18:92:19: d2:c3:fd:60:10:60:5a:ad:e5:29:94:f8:37:1b:5b: e5:41:50:fe:39:b9:1c ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: Grilled Cheese Generated Server Certificate X509v3 Subject Key Identifier: E0:48:57:7E:F9:92:BA:B9:F9:23:41:8D:3D:85:86:82:25:5C:FC:92 X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD DirName:/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us serial:10:01 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ X509v3 Subject Alternative Name: DNS:webby.grilledcheese.us Signature Algorithm: ecdsa-with-SHA384 30:65:02:31:00:b1:ab:4e:4f:21:86:14:12:fe:34:ea:47:00: 67:29:cb:47:70:b2:ad:22:a0:dc:5b:65:7b:22:10:5e:ea:08: 7d:09:8d:c5:77:f5:8b:ff:fa:d2:5b:7a:1e:c6:57:e2:12:02: 30:64:f1:fb:14:ea:cf:b4:20:7d:f3:f5:bc:d0:82:0c:06:03: fc:05:84:5d:f9:37:dc:d6:51:83:7b:8b:f6:91:08:d6:22:4f: 16:96:ff:0a:52:68:47:09:0c:71:90:23:d4 Validation of the webby.cheese.crt.pem file shows the updated x509 fields that define our server certificate: X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: Grilled Cheese Generated Server Certificate The certificate also includes full CRL and OCSP endpoints. X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ And it includes our required subjectAltname. X509v3 Subject Alternative Name: DNS:webby.grilledcheese.us The index.txt file we created for our intermediary certificate now has a new entry. Confirm theCA's database is updated with the newly created certificate. This file will prevent new certificates from being created with the same CN. If you need to recreate the certificate with the same name AND YOU'RE IN A LAB ENVIRONMENT, you can use vi/vim/nano/whatever to delete this line. The production-preferred method is to revoke and reissue. # cat intermediate/index.txt V 180828222314Z 1007 unknown /C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=ocsp.grilledcheese.us/emailAddress=grilledcheese@yummyinmytummy.us V 190906201039Z 1008 unknown /C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Dev Lab/CN=webby.grilledcheese.us/emailAddress=grilledcheese@yummyinmytummy.us The intermediary certificate was responsible for signing the OCSP certificate and our new server certificate; both are listed in the index.txt file. Lastly we can validate the entire certificate chain using the previously created chain.cheese.crt.pem against our newly created server certificate. # openssl verify -CAfile intermediate/certs/chain.cheese.crt.pem intermediate/certs/webby.cheese.crt.pem intermediate/certs/webby.cheese.crt.pem: OK Deploying Your Certificate Your application or server will usually accept PEM format or a PFX bundle which contains certificate, key and certificate chain (if you desire to). In production environments you would not distribute the root certificate along with the intermediate. Even in lab environments, you should distribute the root certificate independently to clients to simulate real world environments. In production systems all mainstream certificate authorities are packaged with operating systems or independent key stores. The intermediary used should match one of these existing root CAs only... For our example, if you were deploying the PEM formatted files, you would need to provide: webby.cheese.key.pem (our server certificate's private key) webby.cheese.crt.pem (our server certificate) int.cheese.crt.pem or chain.cheese.crt.pem (our intermediary CA's certificate or root and certificate concatenated into one file) If you plan to install the certificate and chain in PFX format: # openssl pkcs12 -export -out intermediate/certs/webby.cheese.pfx -inkey intermediate/private/webby.cheese.key.pem -in intermediate/certs/webby.cheese.crt.pem -certfile intermediate/certs/chain.cheese.crt.pem Enter pass phrase for intermediate/private/webby.cheese.key.pem: ****** Enter Export Password: ****** Verifying - Enter Export Password: ****** Validate the PFX bundle # openssl pkcs12 -info -in intermediate/certs/webby.cheese.pfx Enter Import Password: ****** MAC:sha1 Iteration 2048 PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Certificate bag Bag Attributes localKeyID: F7 6B 18 13 DD 04 4E 31 D7 A4 8D AE F5 1F 3B DC AD F3 F8 E8 subject=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Dev Lab/CN=webby.grilledcheese.us/emailAddress=grilledcheese@yummyinmytummy.us issuer=/C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us -----BEGIN CERTIFICATE----- MIIFSDCCBM6gAwIBAgICEAgwCgYIKoZIzj0EAwMwgdIxCzAJBgNVBAYTAlVTMQsw .... lv8KUmhHCQxxkCPU -----END CERTIFICATE----- Certificate bag Bag Attributes: no attributes="" subject=/C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us issuer=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us -----BEGIN CERTIFICATE----- MIID/TCCA4OgAwIBAgICEAEwCgYIKoZIzj0EAwMwgdQxCzAJBgNVBAYTAlVTMQsw .... wO2cWbcYwybr33gTaEdmtUM= -----END CERTIFICATE----- Certificate bag Bag Attributes: no attributes="" subject=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us issuer=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us -----BEGIN CERTIFICATE----- MIIDQTCCAsegAwIBAgIJAP+99S/FDT0CMAoGCCqGSM49BAMDMIHUMQswCQYDVQQG .... /kiTCl//67LTrlpoh9zJLFSNBGh/ -----END CERTIFICATE----- PKCS7 Data Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048 Bag Attributes localKeyID: F7 6B 18 13 DD 04 4E 31 D7 A4 8D AE F5 1F 3B DC AD F3 F8 E8 Key Attributes: no attributes="" Enter PEM pass phrase: Verifying - Enter PEM pass phrase: -----BEGIN ENCRYPTED PRIVATE KEY----- MIIBEzBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQItDjLLd4ozIkCAggA .... GxO/udVd0Bg0zY6eSQV1xyXhGd4GJexnKv/IHeYWjpJMyNqa4O9o -----END ENCRYPTED PRIVATE KEY----- We've completed building a two-tier NSA Suite B certificate authority for use within dev or lab environment. You'll still want to create web services to home the CRL list and act as OCSP Resolvers if you need that level of testing. The big drawback to manually using OpenSSL is the requirement of configuration files for SAN requirements. Manually updating or iterating a new OpenSSL configuration file for each certificate (requiring subjetAltName) is not efficient but I have yet to find a clean script to resolve this. I guess we'll just build one. Later. Notes: (1)The subjectAltNamefieldwas proposed to be preferredinstead of the commonName (CN) field in RFC 2818 by Mozilla's E. Rescorla (who submitted it under his company RTFM, Inc... look up the acronym). No one really knew about it because the RFC also allowed defaulting back to the CN field if no subjectAltName existed. But combined with the seldom read CA/Browser forum's Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates (released April of 2017), the subjectAltName field is now the only field of consequence for defining hostnames or IP's in a certificate. Guess how everyone found about this. Browsers simply removed support for the CN field as the host name and broke everyone's web sites siting "correcting a 17 year old requirement". Fortunately for some of us, our public CA's started auto-populating this field for a several years prior to the browser abandonment and reduced the impact to public sites. However internal CA's were left floundering (unless you read every RFC that comes out and then that doesn't even cover it). Thanks E. Rescorla for your vaugely worded RFC and Google's inability to provide visibility like they did to SHA1 deprecation (with advanced public warning and careful planning). Let's forget that the field is called ALTERNATE NAME... that annoys me at a core level. You have nothing better to do than read every RFC that could potentially affect your life, 17 years down the road... right? (2) OpenSSL Git pull request #341 "Add 'copy and 'move configuration values for DNS Subject Alternative Names" exists in the Post1.1.0 milestone but code commit is still pending into openssl:master branch. So we're stuck with config files for each certificate you want to use for now, unless you want to script it yourselves. Alternativly, OpenSSL has an GIT open Issue #3311 for "Interactivly specify subjecAltName (SAN). Here's to hoping.
HTTPS SNI Monitoring How-to
Hi, You may or may not already have encountered a webserver that requires the SNI (Server Name Indication) extension in order to know which website it needs to serve you. It comes down to "if you don't tell me what you want, I'll give you a default website or even simply reset the connection". A typical IIS8.5 will do this, even with the 'Require SNI' checkbox unchecked. So you have your F5, with its HTTPS monitors. Those monitors do not yet support SNI, as they have no means of specifying the hostname you want to use for SNI. In comes a litle script, that will do exactly that. Here's a few quick steps to get you started: Download the script from this article (it's posted on pastebin: http://pastebin.com/hQWnkbMg). Import it under 'System' > 'File Management' > 'External Monitor Program File List'. Create a monitor of type 'External' and select the script from the picklist under 'External Program'. Add your specific variables (explanation below). Add the monitor to a pool and you are good to go. A quick explanation of the variables: METHOD (GET, POST, HEAD, OPTIONS, etc. - defaults to 'GET') URI ("the part after the hostname" - defaults to '/') HTTPSTATUS (the status code you want to receive from the server - defaults to '200') HOSTNAME (the hostname to be used for SNI and the Host Header - defaults to the IP of the node being targetted) TARGETIP and TARGETPORT (same functionality as the 'alias' fields in the original monitors - defaults to the IP of the node being targetted and port 443) DEBUG (set to 0 for nothing, set to 1 for logs in /var/log/ltm - defaults to '0') RECEIVESTRING (the string that needs to be present in the server response - default is empty, so not checked) HEADERX (replace the X by a number between 1 and 50, the value for this is a valid HTTP header line, i.e. "User-Agent: Mozilla" - no defaults) EXITSTATUS (set to 0 to make the monitor always mark te pool members as up; it's fairly useless, but hey... - defaults to 1) There is a small thing you need to know though: due to the nature of the openssl binary (more specifically the s_client), we are presented with a "stdin redirection problem". The bottom line is that your F5 cannot be "slow" and by slow I mean that if it requires more than 3 seconds to pipe a string into openssl s_client, the script will always fail. This limit is defined in the variable "monitor_stdin_sleeptime" and defaults to '3'. You can set it to something else by adding a variable named 'STDIN_SLEEPTIME' and giving it a value. From my experience, anything above 3 stalls the "F5 script executer", anything below 2 is too fast for openssl to read the request from stdin, effectively sending nothing and thus yielding 'down'. When you enable debugging (DEBUG=1), you can see what I mean for yourself: no more log entries for the script when STDIN_SLEEPTIME is set too high; always down when you set it too low. I hope this script is useful for you, Kind regards, Thomas SchockaertBuilding an OpenSSL Certificate Authority - Introduction and Design Considerations for Elliptical Curves
Introduction Building a certificate authority (CA) for your lab environment is a pain. Until recently I reliedon Jamielinux's OpenSSL Certificate Authority but it slowly lost relevance due to evolutions in Public Key Infrastructure (PKI) requirements, specifically ECC, hash, critical certificate extensions, and revokation changes. Thisguide adheres tocurrent PKI needs namelyRFC 5759 NSA's Suite B Certificate and Certificate Revocation List (CRL) Profile. Before you start burning effigies in the comment section, yes I know ECC curves NIST P-256 and NIST P-384 are not considered "secure" by SafeCurves related to rigidity 1 , ladder 2 , completeness 3 , and indistinguishability 4 . ModernPKI ends up being a slightly religious debate divided across admins who practice provable security versus evangelists preaching mathematically absolute cryptography. I err towards the side of practical and provable security. If we adjusted cryptological practices to comply with every cryptographic sermon, we'd have nothing left to provide our infrastructure that a reasonable number of clients could connect to; forget if my infrastructure can even support it. What Suite B does offer is compatibility with browsers and applications.Complying with popular standards allows us to learn about some of the more overlooked PKI requirements mentioned above. You don't need to fully understand the mathematical intricacies of elliptical curves but you do need to know what your applications and clients can use, especially when certain internet entities quietly drop support for unpopular curves "cough.... Chrome". So many caveats to PKI raise a question of why we're using OpenSSL and why are we building a CA compliant to NSA Suite B (specifically NIST P-384). OpenSSL is free and used by a majority of OS and application vendors. Many admins have familiarity with it's various commands My lab is in AWS and their provided Active Directory offerings do not allow us Enterprise Admin roles; a requirement for setting up Microsoft Certificate Authorities and I am not going to spin up independent AD infrastructure for isolated VPCs We learn OpenSSL commands related to elliptical curves (some of the many) We must pay attention to certificate extension attributes We must create a revocation policy which many existing guides gloss over We must pay attention to OpenSSL's caveat's and limitations to modern PKI requirements, including version support for various features. I tested this series against OpenSSL v1.0.2g (default on Ubuntu 16.04 LTS), and v1.1.0f (manual upgrade to OpenSSL current release). There are some featuers within OpenSSL I am eagerly waiting but are not available as of the current public release. I will keep updating this as requirements and feature become mainstream. This guide is not intended for the hemmoraging edge admin who lives a brazen alpha code lifestyle. Suite B PKI Requirements and CA Design Considerations This guide assists the reader to build a lab-ready CA using elliptical curves for cryptographic signatures and hash functions.RFC 5759 states: Every Suite B cert MUST use the x.509 v3 format and contain An ECDSA-capable signing key, using curves P-256 or P-384 OR An ECDH-capable key establishment key, using curve P-256 or P-384 Every Suite B certificate and CRL MUST be signed using ECDSA. The CA's (Root and Intermediary) MUST be on the curve P-256 or P-384 if the CA contains a key on the curve P-256. If the certificate contains a key on the curve P-384, the signing CA's Key MUST be on the curve P-384. Any certificate and CRL MUST be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key. Suite B PKI follows RFC5280 for marking extensions as critical and non critical. Microsoft helps distill the extension requirements to: subjectKeyIdntifier (SKI), keyUsage, and basicConstraints MUST exist keyUsage MUST be marked as critical keyCertSign and CRLSign MUST be set All other bits (with exceptions for digital signature and non-repudiation) MUST NOT BE SET This guide uses a common and recommended best practiced two-tier PKI hierarchy certificate authority. A two-tier certificate authority consists of: A self-signed root certificate An intermediary certificate signed by the root (completing the two tiers of the certificate authority) A CRL distribution point and OCSP Resolver URI for the intermediary and subsequent client & server certificates (allowing the root to revoke an intermediary certificate) Client and server certificates signed by the intermediary certificate This guide is also designed for lab environments because it do not follow recommended security practices for root CA protection or private key protection. More sensitive or public CA's should follow recommended security practices by storingroot certificate and key offline orin an IT security-ownedHSL (both recommended options for certificate and key protection). Using a dedicated lab CA reduce the exposure of corporate internal resources and limits risk impact to a small subset of machines and should not compromise sensitive data. As you build CA's in other environments like staging or test environments where corporate data may reside, you should increase the security accordingly. Let's go build a CA! Notes: (1) NIST P-384 is not considered rigid, instead considered manipulatable. Coefficients generated by hashing the unexplained seed a335926a a319a27a 1d00896a 6773a482 7acdac73. The curve-generation process has a large unexplained input, giving the curve generator a large space of curves to choose from. Consider, for example, a curve-generation process that takes y^2=x^3-3x+H(s) meeting various security criteria, where s is a large random "seed" and H is a hash function. No matter how strong H is, a malicious curve generator can search through many choices of s, checking each y^2=x^3-3x+H(s) for vulnerability to a secret attack; this works if the secret attack applies to (e.g.) one curve in a billion. (2) NIST P-384 does not apply ladder algorithms (in this case the Montgomery ladder) to compute variations in fixed time, preventing timing and/or power information leakage (side-channel attack). SafeCurves requires curves to support simple, fast, constant-time single-coordinate single-scalar multiplication, avoiding conflicts between simplicity, efficiency, and security. This is not a requirement specifically to use Montgomery curves: there are other types of curves that support simple, fast, constant-time ladders. "Fast" means that implementations of scalar multiplication for the same curve cannot be much faster, and "simple" means that reasonably fast implementations of scalar multiplication for the same curve cannot be much more concise. At this time there are no examples close enough to the edge to warrant quantification of "much". (3) NIST P-384 does not complete single or multi-scalar formulas. SafeCurves requires curves to support simple, fast, complete, constant-time single-coordinate single-scalar multiplication. This includes the SafeCurves ladder requirement but goes further by requiring completeness. SafeCurves also requires curves to support simple, fast, complete, constant-time multi-scalar multiplication. (4) NIST P-384 does not support indistinguishability. SafeCurves note: "Elligator 2" works for any odd prime and any curve of the form y^2=x^3+Ax^2+Bx with nonzero AB(A^2-4B). This includes all Montgomery curves y^2=x^3+Ax^2+x except for one curve y^2=x^3+x. It also includes, after conversion, all Edwards curves x^2+y^2=1+dx^2y^2 except for one curve x^2+y^2=1-x^2y^2. More generally, it includes all curves with points of order 2, except for j-invariant 1728. Standard representations of elliptic-curve points are easily distinguishable from uniform random strings. This poses a problem for many cryptographic protocols using elliptic curves: censorship-circumvention protocols, for example, and password-authenticated key-exchange protocols.
SSL handshake errors
Hi there, Recently put TMOS version 12 into production and see following SSL handshake errors, none of which existed in version 10.2.3: Nov 12 03:15:36 dc1lbc2p info tmm[11446]: 01260013:6: SSL Handshake failed for TCP 72.238.29.206:60819 -> x.x.x.x:443 Nov 12 03:15:55 dc1lbc2p info tmm[11446]: 01260013:6: SSL Handshake failed for TCP 96.241.137.52:50815 -> x.x.x.x:443 Nov 12 03:16:12 dc1lbc2p info tmm[11446]: 01260013:6: SSL Handshake failed for TCP 166.172.187.30:38119 -> x.x.x.x:443 Nov 12 03:16:32 dc1lbc2p warning tmm[11446]: 01260009:4: Connection error: hud_ssl_handler:1135: codec alert (20) Nov 12 03:16:32 dc1lbc2p info tmm[11446]: 01260013:6: SSL Handshake failed for TCP y.y.y.y:63127 -> z.z.z.z:443 Nov 12 03:18:53 dc1lbc2p warning tmm[11446]: 01260009:4: Connection error: ssl_hs_rxhello:7103: unsupported version (40) Did ssldump and ssl debugs but can't figure it out. There are no low encryption ciphers being presented by clients. In fact I don't see any handshake errors in the packet captures. Its pretty baffling. Would be great if someone can throw some light. Techs at F5 haven't been able to figure it out either. Thanks Naresh
SSL Heartbleed iRule update
Get the latest updates on how F5 mitigates HeartbleedGet the latest updates on how F5 mitigates Heartbleed For those of you tuning in to learn more about the OpenSSL Heartbleed vulnerability, here are more details about it and how F5 customers are protected.The iRule below mitigates the Heartbleed vulnerability forvirtual servers that do not use SSL termination. This iRule will find any heartbeat request from a client and close the connection immediately. We believe this is an effective mitigation because we have not seen any clients that send a valid heartbeat request, even if they do advertise heartbeat support. Most of the malicious clients we've seen don't bother to do a full TLS handshake; they start the handshake, then send the malicious heartbeat request. This iRule works even if someone writes a malicious client that negotiates the full SSL handshake then sends an encrypted heartbeat reqest. ############################################## # Name: heatbleed.c rejector irule. # Description: This irule is a tweak to https://devcentral.f5.com/s/articles/ssl-heartbleed-irule-update # Purpose: to block heartbleed requests. # - added check for 768 and 769 ( SSLv3 and TLSv1 ) # - Ensure r is a positive value. This only happens when there is no valid SSL record. # VERSION: 4 - 16.apr.14 ############################################## when CLIENT_ACCEPTED { TCP::collect set s 0 set r 0 } when CLIENT_DATA { set c [TCP::payload length] set i 0 while { $i < $c } { set b [expr {$c - $i}] if { $s } { # skipping payload if { $b >= $r } { set s 0 set i [expr {$i + $r}] } else { set r [expr {$r - $b}] set i [expr {$i + $b}] } } else { # parsing TLS record header if { $b < 5 } { break } binary scan [TCP::payload] @${i}cSS t v r set r [expr {$r & 0xFFFF}] set i [expr {$i + 5}] if { $t == 24 }{ switch -- $v { "768" - "769" - "770" - "771" - "772" { log local0. "Detected Heartbeat Request from [IP::remote_addr]. REJECTING!" reject } } } set s 1 } } TCP::release $i TCP::collect } If you have clients that do issue valid heartbeat requests,we have a server side iRule that will only pass valid short heartbeat responses at the cost of a small performance penalty.
