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!Building 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 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.SSL Heartbleed server side iRule
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 is very similar to the client iRule, except it watches the server responses searching for a heartbeat. If it sees one that is longer than 128 bytes, it rejects the connection. As TCP segments arrive, we pick out the TLS records, which are rarely aligned with the containing TCP segment. The current segment may contain zero or more TLS records. All we know for sure is that the first 5 bytes of the first segment is a TLS record header. In the presentation language of the TLSv1.2 protocol specification (RFC5246), a TLS record is called TLSPlaintext. Here’s the relevant presentation: struct { uint8 major; uint8 minor; } ProtocolVersion; enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; The code will parse the first five bytes of TLSPlaintext, which includes the fields type, version and length. Because these are always unencrypted, we use these bytes to determine if the server is sending an exceptionally long heartbeat response message. If we see the attack, we log and reject the connection. If the attack is not seen, we must skip the fragment, then look for another record header. This script is almost identical to the client-side script we posted yesterday. But because there’s so much more data in a typical web server stream, this one will affect performance a bit more than the previous. The advantage here is that by examining the length of the heartbeat response, we can more reliably detect the attack, allowing non-attack heartbeats through. It was difficult to find an off-the-shelf client that would actually send benign heartbeat requests. We just scripted one up for testing purposes. Curl and other OpenSSL-based clients will typically run with the library’s default behavior, which is to advertise support for heartbeats, but never actually send them. If that’s true on your network, then use the client-side script we posted yesterday. If not, and you have valid uses of the client-side heartbeats, then use this script. ############################################## # Name: Server side block_heartbleed iRule. # Description: This irule will detect a long TLS heartbeat response # and reject the TCP connection. It uses TCP::collect and TCP::release # more efficiently, which results in a much lower performance # penalty compared with the previous version. # VERSION: 2 - 12.apr.14 ############################################## when SERVER_CONNECTED { set Debug 1 set HB_Size_Max 64 TCP::collect 5 } when SERVER_DATA { set Buf_Len [TCP::offset] set Skip_Len 0 set Collect_Len 0 while { $Collect_Len == 0 && $Buf_Len > 0 } { set Skip_Len 0 set Collect_Len 0 # Start of new Rec(s) binary scan [TCP::payload] cSS Rec_Type Version Rec_Len if { ($Rec_Type == 24) } { if { $Rec_Len > $HB_Size_Max } { if { $Debug > 0 } { log local0. [format "BIG HEARTBEAT len %i; conn reset" $Rec_Len $Rec_Len] } reject return } elseif { $Debug > 1 } { log local0. [format "HEARTBEAT len %i (%#x)" $Rec_Len $Rec_Len] } } TCP::release 5 incr Buf_Len -5 # From current buffer, release as much data as possible. if { $Rec_Len > 0 } { # Partial data. Prepare to passthru remainder, then collect next header. if { $Buf_Len < $Rec_Len } { TCP::release $Buf_Len incr Rec_Len -$Buf_Len set Skip_Len $Rec_Len set Collect_Len 5 } else { # Complete data. TCP::release $Rec_Len set Rec_Len 0 } } set Buf_Len [TCP::offset] # If buffer does not contain full next header, prepare to collect. if { $Buf_Len < 5 } { set Collect_Len 5 incr Collect_Len -$Buf_Len } if { $Collect_Len > 0 } { if { $Skip_Len > 0 } { TCP::collect $Collect_Len $Skip_Len } else { TCP::collect $Collect_Len } } } return } With this new iRule, you can be assured that your servers will not leak information.Security Sidebar: LibreSSL is forking OpenSSL
The Heartbleed vulnerability revealed a serious flaw in the way OpenSSL is implemented. One could argue that this flaw was big enough on its own to cause users to abandon OpenSSL. Or, maybe some users had experienced previous frustrations with OpenSSL, and the Heartbleed bug was what sent them over the edge and on their way to search for a different toolkit for implementing SSL/TLS. One specific group of software developers claim they aren't gonna take it anymore. And they built a crappy website to prove it. LibreSSL is clearly distraught over the recent problems with OpenSSL, and they're doing something about it. Libre: denotes "the state of being free" as in "having freedom" or "liberty" Maybe they chose the word "Libre" because their version of the SSL/TLS protocol is free (but so is OpenSSL), or maybe it's because they want to be free from the recent problems with OpenSSL. Either way, LibreSSL is forking the OpenSSL code and going their separate way. LibreSSL is primarily developed by the OpenBSD Project and is supported financially by the OpenBSD Foundation and the OpenBSD Project. You too could donate to their cause! They are so focused on code development that they even built their webpage to annoy "web hipsters". The only way to stop the madness of their current web design is to donate to their cause. The LibreSSL project wants to remove a large portion of OpenSSL code that is of very limited interest to most users or that was scheduled to be removed by the OpenSSL team but never was. Theo de Raadt, founder of OpenBSD, said that the project has already removed 90,000 lines of C code and 150,000 lines of content from the OpenSSL code. They also have almost 3,100 commits built as of this article. But even with all those changes, he claims that the LibreSSL codebase is still API compatible. F5's own David Holmes posed a great question related to this code change: "So much code is changing, and LibreSSL developers say the API is still compatible, but what exactly are they doing?" The Struggles of OpenSSL The purpose of the OpenSSL project (started in 1998) was to develop a robust and Open Source toolkit that implements SSL/TLS and provides a full-strength cryptography library that is managed by the OpenSSL community. The OpenSSL project was historically volunteer driven, and doesn't have any specific requirements to become a volunteer other than a strong willingness to contribute while following the project's goals. The current staff consists of 8 active members...one from the US and all the others from Europe. The project has an annual budget of less than $1 million, and at least part of their budget comes from donations. You might think that a team of 8 people with less than $1 million per year would not make much of an impact in today's high-tech world, but the truth is that, as of this year (2014), two-thirds of all webservers on the Internet use OpenSSL! The other truth is that a small team of underpaid (albeit very intelligent and competent) staff members and a host of volunteers will miss things from time to time (sometimes really BIG things). All the software is open-source, so you could evaluate and test it prior to using it on your webservers, but most companies just trust that it will work...and work correctly. Let's be honest, even if you did crack open the code, your company probably doesn't have anyone on staff to figure out what it's doing anyway. The OpenSSL team is dedicated to their important work, but it's hard to keep up when you have such a small staff and a very limited budget. In fact, the OpenSSL Software Foundation President (Steve Marquess) recently spoke about the staff and said "these guys don’t work on OpenSSL for money. They don’t do it for fame. They do it out of pride in craftsmanship and the responsibility for something they believe in. I stand in awe of their talent and dedication..." Marquess went on to call out the big companies who rely on OpenSSL but never provide funding to their team. "I’m looking at you, Fortune 1000 companies. The ones who include OpenSSL in your...products that you sell for profit...The ones who have never lifted a finger to contribute to the open source community that gave you this gift. You know who you are." Theo de Raadt (Mr. OpenBSD) has a slightly different view of this team, claiming "OpenSSL is not developed by a responsible team." Theo versus Steve...you decide who is right. Frankly, I can see the point from both guys. Unanswered Questions... As the LibreSSL project forks OpenSSL, we are left with some intriguing and important questions. David Holmes sent me a list of thought-provoking questions, and I wanted to include them in this article. As LibreSSL digs through the OpenSSL code, will they find any other major vulnerabilities like Heartbleed? What if OpenSSL team doesn’t accept all the changes from LibreSSL? Who is going to “resolve” changes from OpenSSL into LibreSSL moving forward? Are the library names in LibreSSL going to stay the same as OpenSSL? If so, does that mean they are mutually exclusive? Software forking is not always a bad thing, but many times it creates competing projects that split the developer community. There's no overarching governing body that can mandate standardization and harmony between these two groups. In the end, you might have to decide which way to go...stick with OpenSSL or switch to LibreSSL. I suspect OpenSSL will stay in place until a major company adopts LibreSSL and paves the way for change. But in the end, will LibreSSL suffer the same fate as OpenSSL with little funding and limited staff support? We shall see...Wat is Heartbleed?
Get the latest updates on how F5 mitigates HeartbleedGet the latest updates on how F5 mitigates Heartbleed Heartbleed is nu al even in het nieuws en lijkt zijn impact nog steeds uit te breiden. Verschillende sites blijven updates versturen van de log-in handelingen om gebruikers gerust te stellen dat hun data veilig is. Andere sites melden dat ze slachtoffer zijn geworden, en dat een ander wachtwoord noodzakelijk is. Hoe serieus moeten we Heartbleed nemen? De meningen lopen uiteen van ‘gewoon weer een gat in de verdediging’ tot ‘dit is een revolutionair security-issue’. De gematigde reactie komt meestal voort uit de constatering dat ‘slechts’ 17 procent van de sites is geraakt. Maar er is ook nog de impact op gadgets en apparatuur die we snel over het hoofd zien. Heel veel smartphones, IP-telefoons, switches en routers worden aangemerkt als kwetsbaar. Internetrouters voor thuisgebruik en de hippe e-thermostaten zijn allemaal mogelijk slachtoffer. En terwijl het Internet of Things steeds meer apparatuur koppelt, wordt die lijst alleen maar langer. Veel van deze apparaten zullen niet worden geupdate, waardoor bedrijven die ermee werken en communiceren gevaar lopen. Zij hebben behoefte aan een beveiligingsoplossing die los staat van het wel of niet updaten van het apparaat zelf. Aangezien er veel aandacht voor is zullen de leveranciers haast over elkaar vallen met een passend aanbod om gebruikers te beschermen tegen Heartbleed. Netwerkapparatuur zal in stelling worden gebracht om verzoeken die gebruik maken van het lek te detecteren en tegen te houden. Er zijn verschillende plekken in het dataverkeer waar je dit lek en vergelijkbare kwetsbaarheden kunt tegenhouden. Bedrijven moeten het meest strategische punt kiezen in het netwerk. Om dat punt te bepalen, moet je je afvragen hoe en in welke situatie de kwetsbaarheid wordt gedetecteerd. Waarom dat van belang is, is het goed om te kijken naar hoe Heartbleed werkt. Werkwijze Heartbleed Heartbleed maakt gebruik van een ontbrekende lengte-controle in de OpenSSL code-afhandeling van een relatief onschuldige uitbreiding van het TSL/SSL protocol (gedefinieerd in RFC 6520). Het gaat om twee simpele berichten: een verzoek en een antwoord. Dit verzoek kan door zowel de client als de server worden verstuurd om de connectie in stand te houden. De verzender stuurt een HeartbeatMessage met een klein data-pakketje, in verwachting dat de ontvanger diezelfde data terugstuurt. Belangrijk hierbij is dat degene die het bericht verstuurt de omvang van het antwoord bepaalt. De verzender geeft aan de ontvanger door hoeveel dat hij verstuurt en hoeveel hij dus terug verwacht. De OpenSSL-code zou ervoor moeten zorgen dat de lengte die de aanvaller zegt te versturen daadwerkelijk beschikbaar is. Maar dat doet de code dus niet. Hij vertrouwt de verzender simpelweg en pakt gewoon de hoeveelheid data uit het geheugen. Op die manier kan een aanvaller toegang krijgen tot data in het geheugen en dus informatie als wachtwoorden en sleutels. Bescherming tegen Heartbleed Aangezien Heartbleed gebruik maakt van een kwetsbaarheid in versleutelde communicatiepaden moet de oplossing ook daarin worden gerealiseerd. Er zijn drie punten waar je dat kan doen. 1. Client - Je kunt het client OS en apparatuurtype controleren en dit afzetten tegen het bekende gebruik van de geraakt OpenSSL versies. Eenmaal gedetecteerd kan een client blijvend afgewezen worden, zodat het kwaadwillende verzoek sowieso niet gestuurd wordt. Echter, een client afwijzen omdat het mogelijk een kwaadwillende is, kan resulteren in boze, legitieme gebruikers, klanten of andere relaties. 2. Request - Inspecteer client-verzoeken en wijs het af, zodra een HeartbeatMessage wordt ontdekt. Dit voorkomt dat de verzoeken worden doorgestuurd naar kwetsbare systemen en servers. 3. Response - Onderzoek antwoorden, en zodra er een HeartbeatMessage tussenzit, controleer de lengte. Als die groter is dan wenselijk of gebruikelijk, negeer het. Op die manier ontvangen aanvallers niet je data, maar zijn inmiddels je servers en data wel blootgesteld. De juiste plek om bescherming te implementeren is de plek die je een keuze biedt tussen verschillende oplossingen. Of op alledrie de punten als je echt helemaal dichtgetimmerd wil zijn. In de meeste gevallen zal de application delivery firewall of application delivery controller de meest strategische plek zijn. De juiste oplossing staat echter niet alleen op de juiste plek in het netwerk. Het zorgt ook voor zichtbaarheid en programmeerbaarheid van de netwerk-stack en is in staat data te vinden die wijzen op een lek, bewust of onbewust. Een goede tool maakt onderscheid in client en server verkeer en past de benodigde logica toe. De logica die Heartbleed aan de client-kant ontdekt is anders dan die aan de server-kant. In geval van de client moet het op zoek gaan naar een specfiek bericht gericht op een Heartbleed-verzoek, of de omgeving van het client-apparaat onderzoeken. Aan de server-kant moet het de grootte van de response controleren. Elk geval vraagt om zijn eigen, unieke code. De tool moet dus een programmeerbare omgeving hebben die zeer nauwkeurig de juiste logica kan toepassen op het juiste moment. Nu Heartbleed een goede week zijn slag slaat moeten organisaties redelijkerwijs zicht hebben op de impact binnen hun bedrijf. Uiteraard zijn server patches en upgrades noodzakelijk, en de toewijzing van nieuwe sleutels en wachtwoorden. Ondertussen blijven servers (en dus gebruikers) kwetsbaar. Bedrijven moeten dus direct in actie komen, terwijl er ook gewerkt moet worden aan een oplossing voor de langere termijn. Dit artikel is gepubliceerd: - Infosecurity magazine http://infosecuritymagazine.nl/2014/04/18/wat-is-heartbleed/ - Computable (including some nice comments and feedback by Gert Jan) http://www.computable.nl/artikel/opinie/netwerkbeheer/5058876/4480198/wat-is-heartbleed-en-hoe-bescherm-je-jezelf.html - BlogIt http://www.blogit.nl/wat-heartbleed-en-welke-methode-biedt-bescherming
