The layman’s guide to X.509 certificate jargon
Published Mar 17 2021 08:00 AM 14.6K Views
Microsoft

Is there anything more fraught than managing device certificates? Probably, but you generally don't encounter subatomic physics in IoT*. In the case of certificates, it does not help that we treat them like the proverbial student treats math, aka we are intimidated by the subject and hide instead of explore, learn, and embrace. I always liked math, and I will be your guide explaining the words we use when we talk about X.509 certificates. There are many terms because they are all precise, not because they are really complicated. There will be a vocabulary quiz, and that quiz is called "sounding competent in front of your manager." Join me today as I define some certificate terminology in a non-threatening way. Terms are presented by relation to one another.

*Feel free to leave links to subatomic physics IoT projects if you know of any!

X. 509 certificate or device client certificate
Type of certificate used in IoT with a strict hierarchy of signing certificates (unlike PGP which is more web-like). This type of certificate is commonly used to identify IoT devices due to its strength. This can also be called a device client certificate.

 

X.509 thumbprint
The thumbprint of a certificate is basically a shortened version of the full-chain certificate. It is created by hashing the certificate – basically doing math on a certain encoding of the certificate that returns a unique result.

 

Server certificate
The server certificate is how the device authenticates the service it is attempting to connect to. In order to do this, the device must have the public key for the service/server it is attempting to connect to so it can verify the server using public key cryptography.

 

Public key cryptography
This is a blog post for another time. For the sake of this document, it’s the fancy math by which clients and servers authenticate each other using asymmetric keys.

 

Asymmetric key
In public key cryptography, the fancy math involved uses two very large prime numbers that are the only two factors of an even bigger number. The two very large prime numbers are both keys, and generally one is shared (public) and one is kept hidden (private). Because the two very large prime numbers are different, they are called “asymmetric.” Unlike symmetric keys, the two parties involved in the information exchange have different keys that they use to encrypt and decrypt messages.

 

PKI
Public Key Infrastructure. The machinery that handles hosting CAs and signing certificates

 

Signing
This is fancy math that boils down to a trusted certificate saying it trusts whatever it is signing.

 

Certificate issuance
This is the term for the process by which a certificate is given out.

 

Self-signed certificate
The general term for a certificate whose source of trust comes from that certificate itself. A self-signed cert can either be a CA or a leaf certificate. Being self-signed does not necessarily mean the certificate is less trustworthy than a certificate signed by a CA, it just means that you trust the cert directly instead of trusting the signing entity.

 

Signed certificate or CA signed certificate
This is the general term for any certificate whose trust comes from being signed by a signing certificate. You trust this certificate because you trust the signer.

 

X.509 Certificate Authority or CA or signing CA
CA stands for Certificate Authority. Generic term for a certificate that is a source of trust. Signing certificates can either be root CAs or intermediate CAs. Think of a signing CA like the fancy holographic seal embedded in a driver’s license - you trust the driver’s license is real because you trust the Washington State Department of Licensing to only issue a license to a valid driver. (For folks outside the US, the analogy holds true for passports too).

 

Signing CA support
We hear this request from customers. This could mean either being able to authenticate a device using your CA, or it could mean being able to integrate your signing CA into Azure IoT to authenticate/rotate device certs. This is ambiguous, so please make sure you clarify when you talk with the product team.

 

Root CA
The ultimate source of truth for a certificate chain. Root certificates are self-signed, which means that they trust themselves, and they can also sign other certificates (aka place trust in that device, like saying "I'm Nicole and I approve this message"). Because they are the root of trust for other applications, there are often strict requirements around how they can be stored and rotated. Root CAs are a type of signing CA.

 

Intermediate CA or ICA
Intermediate CAs are a type of signing certificate that has trust placed in it by another signing CA (either root CA or another ICA) and are used to place trust in other certificates. A device can have any number of ICAs in its certificate chain, though typical IoT devices have between 2-4 levels.

 

Leaf certificate or device certificate or identity certificate
This is the identity cert for a device. "Leaf" means it is the terminus for the certificate chain; leaf certificates are not allowed to sign other certs (aka not allowed to place trust in other certs). The leaf certificate does not have to be signed by a signing certificate, although they often are. Leaf certificates can also be self-signed.

 

Certificate chain
The certificate chain is the chain of trust, from root CA to leaf certificates with some number of ICAs in the middle. The chain of trust is like when you get a job because your brother's roommate's cousin vouches for you when you apply for a job. In my made-up case, the chain of trust goes: cousin [trusts] roommate [trusts] brother [trusts] you. You are the leaf certificate asking to be trusted, and you are trusted because the chain of trust leads to the cousin who roots the trust in your ability.

 

Full chain certificate
Devices can either present their leaf certificate or their full chain certificate when they authenticate. The leaf certificate only has information about the CA that directly signed the leaf certificate, but it does not have information about the other CAs involved in the chain of trust for that device. The full chain certificate contains information about all of the links in the certificate chain, from root CA through to leaf certificate.

 

Public CA
Public CAs are CAs trusted by web browsers. They are called "public" because they are intended for the general public to trust them, and thus there is a set of requirements a PKI must go through in order to provide public CAs.

 

Private CA
"Private" means "not trusted by web browsers by default." Private CAs are meant to be trusted in a limited context, such as within a given company or a different business case. Private CAs can be provided by a 3rd party provider or from a company's own internal PKI.

 

Levels
Number of links in the cert chain. The number of levels can vary depending on how your certificate organization mirrors your company organization.

 

Certificate rotation
Certificates have an expiration date, just like passports and drivers licenses. Rotating a certificate means renewing the certificate with a longer expiration date, just like renewing your drivers license or passport. For devices, this means sending a certificate signing request (CSR) to a CA and updating the services to accept the new cert.

 

Primary certificate
Generally, this refers to a certificate used by the service to identify the device. The primary certificate is the main certificate used to identify a device. During certificate rotation, this certificate stops being trusted in favor of the secondary certificate.

 

Secondary certificate
Generally, this refers to a certificate used by the service to identify the device. The secondary certificate is the “backup” certificate that is next in line if something happens to the primary. During certificate rotation, the primary certificate stops being trusted, and the secondary certificate becomes the (new) trusted primary. Then a new secondary certificate is added.

 

Certificate signing request or CSR
A CSR is basically a formal request to a CA to place trust in a certificate. Think of it like the application for a new driver’s license – once approved, the DMV gives you a new license. Similarly, when a device sends a CSR, the signer sends back a signed certificate.

 

Manufacturing certificate
This is an Azure-specific term for the credential installed on the device during manufacturing. This is used for onboarding before being issued an operational certificate. Think of this as the device’s birth certificate – it tells where the device came from and does not get renewed, but it is not useful for knowing what the device is used for today. The manufacturing certificate can be used as the operational certificate, but we recommend they be separate.

 

Operational certificate
This is an Azure-specific term for the credential used by the device when it connects to a solution. Think of this as the device’s driver’s license – the device uses this on a day-to-day basis, but it needs renewing regularly.

 

ECC
Elliptic Curve Cryptography. This has to do with the math used to generate the certificate. ECC certificates tend to be smaller than RSA certificates and thus better for use on resource- or bandwidth-constrained devices. Unless you are a security person, I would not worry about this – just think about it like a flavor of ice cream, like vanilla or chocolate.

 

RSA
Rivest-Shamir-Adleman, named after the people who developed the algorithm. This has to do with the math used to generate the certificate. Unless you are a security person, I would not worry about this – just think about it like a flavor of ice cream, like vanilla or chocolate.

 

Public key or public portion certificate
This is the part of the certificate that is shared to all entities who might want to establish trust with the device, e.g. prove that a message sent by the device originated from the device itself and not an imposter. Think of the public key as the decoder ring for messages sent by the device: the decoder ring only works for the particular code used by the device. If the decoder ring can read a message, that means the correct secret code was used and thus the message is genuine. If this key gets leaked, it is not the end of the world.

 

Private key or private portion certificate
This is the part of the certificate that the device uses to prove its identity via fancy math done on the device itself. The public key is used to “undo” the fancy math, and if the result isn’t gibberish then the device has proved its identity. The private key should never leave the device and must be protected, ideally in specialized hardware storage called a secure element. When a device is compromised, generally that means that someone has stolen the private key and your device should no longer be trusted.


Let me know in the comments if there are other certificate terms that are not covered that you’d like to see defined.

 

To sum things up with a limerick:

Certificates can complicate
But don't let your mind fill with hate
This list of vocab
Is sure to be fab
To keep terminology straight

3 Comments
Copper Contributor

Can you give some insights on the following points:

1) Use of Blockchain in PKI

2) How to handle self signed key installed in a HSM of device which need to be provisioned in IoT Hub compared to openSSL created X.509 certificate

3) Is there any other authority certificates  apart from open SSL which Azure supports for auto-device provisioning?

 

4) Can you provide some insights about the history and significance of CA signed and self signed certificates ?

Brass Contributor

PKCS 7 

Tüm sertifikaları ekleyebileceğiniz sertifika Formu

 

Copper Contributor

oh, I have a quantum mechanical problem. I have an iot hub device. AWS certificates work fineIt works well.png. Azure certificates work wrongIt works bad.png, what can I do?

Co-Authors
Version history
Last update:
‎Mar 15 2021 02:54 PM
Updated by: