For context, check the intro post.
Summary: How to use Signed Certificates in an IoT supply chain. Without giving away your private keys to your subcontractor.
At the end of this post, you completed 60% of the end-to-end process.
You will generate an Intermediate Certificate for your supplier. They can then use that to sign Things on your behalf.
No private keys will be shared. The subcontractor can generate their own private key and generate a certificate request based on that.
We as Root CA can then generate a valid certificate based on the request, without the need to get the subcontractor's key.
Subcontractor Generates Request for a Certificate
Prepare the intermediate certification infra.
mkdir louisiana cd louisiana mkdir certs crl csr newcerts private chmod 700 private touch index.txt echo 1000 > serial echo 1000 > crlnumber
In the louisiana folder; create a file called openssl.cnf, Adapt where appropriate.
# OpenSSL intermediate CA configuration file. # Copy to `/root/ca/louisiana/openssl.cnf`. [ ca ] # `man ca` default_ca = CA_default [ CA_default ] # Directory and file locations. dir = /home/avnet/.openssl_certification_authority_USM/ca/louisiana certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # The root key and root certificate. private_key = $dir/private/louisiana.key.pem certificate = $dir/certs/louisiana.cert.pem # For certificate revocation lists. crlnumber = $dir/crlnumber crl = $dir/crl/louisiana.crl.pem crl_extensions = crl_ext default_crl_days = 30 # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no policy = policy_loose [ policy_strict ] # The root CA should only sign intermediate certificates that match. # See the POLICY FORMAT section of `man ca`. countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_loose ] # Allow the intermediate CA to sign a more diverse range of certificates. # See the POLICY FORMAT section of the `ca` man page. countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] # Options for the `req` tool (`man req`). default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 # Extension to add when the -x509 option is used. x509_extensions = v3_ca [ req_distinguished_name ] # See <https://en.wikipedia.org/wiki/Certificate_signing_request>. 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 = BE stateOrProvinceName_default = Brussels Capital District localityName_default = Schaarbeek 0.organizationName_default = United States Manufacturing organizationalUnitName_default = emailAddress_default = email@example.com [ 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 [ 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 [ usr_cert ] # Extensions for client certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = client, email nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, emailProtection [ server_cert ] # Extensions for server certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth [ validation_cert ] # Extensions for IoTConnect and Azure CA validation certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = client nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth [ crl_ext ] # Extension for CRLs (`man x509v3_config`). authorityKeyIdentifier=keyid:always [ ocsp ] # Extension for OCSP signing certificates (`man ocsp`). basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning
You are doing the next two steps, but in reality they are done by the 3rd party on their systems:
Supplier Generates Private Key
openssl genrsa -aes256 \ -out louisiana/private/louisiana.key.pem 4096 chmod 400 louisiana/private/louisiana.key.pem
Never ask the supplier for the .key.pem file nor the password. You don't need it, and they should not share it with anyone.
Supplier Generates a Request for the Intermediate Certificate
Use these parameters (1st exact the same as Root, 2nd should identify the intermediate):
Org name: United States Manufacturing
CN: Louisiana Branch Intermediate CA
openssl req -config louisiana/openssl.cnf -new -sha256 \ -key louisiana/private/louisiana.key.pem \ -out louisiana/csr/louisiana.csr.pem
This request has to be handed over by the subcontractor to the Root CA (you).
Root CA Generates Intermediate Certificate for Supplier
You, the Root CA, will now generate an intermediate certificate for the subcontractor.
It will be based on the request they generated in the step above.
The certificate is powerful. They can create new certificates on our behalf, based on it. Even other intermediate certificates.
That makes sense. They may want to also delegate the final certificate generation to an employee.
It makes sense for the subcontractor to generate an intermediate CA certificate to each employee. Only the employee knows their private key and password.
It keeps the cycle traceable and safe. No one needs to share the secrets.
In this exercise, we will not add an additional intermediate CA. The supplier will use their intermediate certificate directly to generate final (leaf) certificates for the things they produce.
Generate the Intermediate CA Certificate
The password asked is that of yourself, the Root CA.
openssl ca -config openssl.cnf -extensions v3_intermediate_ca \ -days 3650 -notext -md sha256 \ -in louisiana/csr/louisiana.csr.pem \ -out louisiana/certs/louisiana.cert.pem chmod 444 louisiana/certs/louisiana.cert.pem
Validate the Certificate
cat index.txt openssl x509 -noout -text \ -in louisiana/certs/louisiana.cert.pem openssl verify -CAfile certs/ca.cert.pem \ louisiana/certs/louisiana.cert.pem
Create the Intermediate Certificate Chain
To be able to use the Root CA Certificate as validation, the downstream certificates should contain the Root CA.
Every step will add their certificate to the chain, including the thing.
If you don't do that, you'd have to register intermediate certificates in the server's trusted root database.
You don't want that. You want to validate against your Root CA only.
I step away from the article I based the steps on. Azure requires the order Leaf -> ... -> Intermediate CA -> ... -> Root CA.
cat \ louisiana/certs/louisiana.cert.pem \ certs/ca.cert.pem \ > louisiana/certs/ca-chain.cert.pem chmod 444 louisiana/certs/ca-chain.cert.pem
You as Root CA give that signed certificate to the subcontractor together and the chain and your Root certificate.
They can now start programming devices and generate their certificates for you.
What Have You Achieved: 60%
You generated and installed a root certificate on IoTConnect Cloud.
You built a major part of the infrastructure that you will later use to generate the intermediate certificates.
Subcontractor generated a private key and a certificate request. They gave you the request file.
You generated the intermediate CA certificate and signed it with your Root CA private key.
You gave the certificate, your own root certificate, and the chain up to that point, to the supplier.
Next article: The supplier generates certificates while programming your Things.