This site presents technical information about digital certificates, their use cases, as well as related data formats and protocols. Whether you want to run your own PKI, or use one, you will find some useful information how to deal with it.

If you have feedback or want to contribute, please open an Issue or a Pull Request on GitHub.

• Important Data formats

  • ASN.1 with DER and PEM

  • X.509

  • PKCS#12

  • PKCS#10

  • PKCS#7/CMS

  • SSH and PKCS#8 (?)

• Enrollment Protocols

  • SCEP

  • ACME

  • EST

• Other Protocols or Standards

• Tools

  • certutil

  • guiDumpASN

  • OpenSSL/LibreSSL

• Families of Cryptography Algorithms

  • Hashes

  • Symmetric Cryptography

  • Asymmetric Cryptography
• Certificate Use Cases

  • Authentication

    • WiFi

    • VPN
• Other stuff

  • Certifried attack

  • Managing Certificate Lifecycles with CRL, OCSP, ...

What are the two types of key-based encryptions that exist?

The two main types of key-based encryptions are symmetric encryption and asymmetric encryption.

Symmetric Encryption

• Key Usage: Uses a single key for both encryption and decryption.

• Speed: Generally faster and more efficient.

• Security: The main challenge is securely sharing the key between parties.

• Examples: AES (Advanced Encryption Standard), DES (Data Encryption Standard).

Asymmetric Encryption

• Key Usage: Uses a pair of keys – a public key for encryption and a private key for decryption.

• Speed: Slower compared to symmetric encryption due to more complex computations.

• Security: More secure for key distribution since the private key is never shared.

• Examples: RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography).

Which type of encryption is considered more secure?

Both schemes are considered secure in the sense that if you are using a modern algorithm with a sufficient key length, no current computer can break the cipher.

Which type of encryption is better depends on the use case, but many use cases require asymmetric encryption, because it uses a pair of keys – a public key for encryption and a private key for decryption. The private key is kept secret, which enhances security since it never needs to be shared.

Which type of encryption is better for Bulk Data?

Symmetric Encryption, because it is faster.

What is the general process for Hybrid encryption?

1. Key Generation: The sender generates a fresh symmetric key (also known as a session key) for encrypting the actual message.

2. Message Encryption: The sender uses the symmetric key to encrypt the plaintext message, producing a ciphertext.

3. Key Encryption: The sender then encrypts the symmetric key using the recipient’s public key (asymmetric encryption).

4. Transmission: The sender sends both the encrypted message (ciphertext) and the encrypted symmetric key to the recipient.

PKCS#7 is part of the Public Key Cryptographic Standards. You might have guessed it, but it is the seventh of these standards. Its successor CMS is mostly backwards compatible and therefore other dependant standards may refer to either PKCS#7 or CMS, depending on their own version. Therefore, we sometimes use the PKCS#7 and CMS interchangeably on this site.

This is also the major disadvantage of this format. If an application or user gets a PKCS#7, it is not by itself clear what to do with it. Here are some important use cases:

• S/MIME messages are basically emails with PKCS#7 bodies or attachments.

• requests and replies are both actually PKCS#7 signed messages.

• EST responses are CMS messages.

Encoding

Common file endings are .p7b (), .p7s (a signed message or message signature), and .p7m (a signed and/or encrypted message). The with label "PKCS7" is also defined, but seldom used.

Tools

In Windows, you can open PKCS#7 messages with a double click and the Crypto-shell extensions will display it for you. However, you can usually only extract certificates and their private keys out of it, and not message contents.

You can convert these files into other formats with tools like OpenSSL.

What are two questions a client must ask when receiving a certificate from a server?

1. Is the certificate valid and trusted? The client needs to verify that the certificate is issued by a trusted Certificate Authority (CA) and that it hasn’t expired or been revoked. This involves checking the certificate’s validity period and ensuring it is signed by a CA that the client trusts.

2. Does the certificate match the server’s identity? The client must ensure that the certificate’s details, such as the Common Name (CN) or Subject Alternative Name (SAN), match the server’s domain name. This helps confirm that the certificate is indeed intended for the server the client is trying to connect to.

How does the client validate that a certificate can be trusted?

1. Check the certificate chain of trust: The client verifies the certificate chain, which includes the server’s certificate, any intermediate certificates, and the root certificate. Each certificate in the chain must be signed by the next higher authority, ultimately leading to a trusted root certificate.

2. Verify the certificate’s validity period: The client checks the certificate’s validity period to ensure it hasn’t expired or isn’t yet valid. This involves checking the “Not Before” and “Not After” dates on the certificate.

3. Match the certificate to the server’s identity: The client ensures that the certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the server’s domain name. This confirms that the certificate is intended for the server the client is connecting to.

How does the client validate that the server is the true owner of a certificate?

1. Certificate chain verification: The client verifies the certificate chain, ensuring that each certificate in the chain is signed by a trusted Certificate Authority (CA). This chain starts from the server’s certificate and ends at a trusted root certificate.

2. Domain name matching: The client checks that the certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the server’s domain name. This ensures that the certificate is intended for the server the client is connecting to.

3. Digital signature verification: The client verifies the digital signature on the certificate using the public key of the issuing CA. This ensures that the certificate has not been tampered with and is indeed issued by a trusted CA.

Why is ownership important if you have already checked that the certificate is trusted?

Certificate validity and trust: This step ensures that the certificate is issued by a trusted Certificate Authority (CA), is within its validity period, and hasn’t been revoked. It confirms that the certificate is legitimate and hasn’t been tampered with.

Server identity verification: Even if a certificate is valid and trusted, it must also be confirmed that it belongs to the server you’re connecting to. This involves checking that the certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the server’s domain name. This step ensures that the certificate is intended for the specific server, preventing man-in-the-middle attacks where an attacker might present a valid certificate for a different domain.

What are the two methods the client answers this question? What are the two results which occur with either methods?

1. Domain Name System (DNS) verification: The client checks that the certificate’s Common Name (CN) or Subject Alternative Name (SAN) matches the server’s domain name.

   Result:

   • Match: If the names match, the client can proceed with the connection, confident that the certificate is intended for the server.

   • Mismatch: If the names do not match, the client will likely terminate the connection or display a warning, indicating a potential security risk.

What determines which method gets used?

Domain Name System (DNS) verification:

• Usage: This method is always used as part of the TLS handshake. The client checks the certificate’s Common Name (CN) or Subject Alternative Name (SAN) against the server’s domain name to ensure they match.

• Determining factors: This is a standard part of the TLS protocol and is automatically performed by the client when establishing a secure connection.

Public Key Infrastructure (PKI) verification:

• Usage: This method is also always used during the TLS handshake. The client verifies the digital signature on the certificate using the public key of the issuing Certificate Authority (CA).

• Determining factors: This is another standard part of the TLS protocol. The client will automatically perform this check to ensure the certificate is valid and has not been tampered with.

Which certificates should the server send to the client?

During the TLS handshake, the server should send the following certificates to the client:

• End-entity certificate: This is the server’s own certificate, which proves its identity to the client.

• Intermediate certificates: These certificates link the end-entity certificate to the trusted root certificate. They help establish a chain of trust from the server’s certificate back to a trusted root certificate.

What are Domain Validation and Extended Validation certificates?

Domain Validation (DV) certificates are a type of TLS certificate where the Certificate Authority (CA) verifies that the applicant has control over the domain. This is typically done by:

• Responding to an email sent to the domain’s administrative contact.

• Adding a DNS TXT record.

• Uploading a file to the web server.

Key characteristics:

• Quick issuance: They can be issued quickly, often within minutes, as they require minimal validation.

• Basic security: They provide encryption and basic assurance that the domain is controlled by the entity requesting the certificate.

• Cost effective: Often cheaper or even free, making them accessible for small websites and personal projects.

Extended validation (EV) certificates are a higher level of TLS certificate that requires a more rigorous validation process. The CA verifies the legal, physical, and operational existence of the entity requesting the certificate. This includes:

• Confirming the legal identity and status of the entity.

• Verifying the entity’s physical and operational presence.

• Ensuring the entity has exclusive rights to use the domain.

Key Characteristics:

• High assurance: Provides the highest level of trust and assurance to users, as it involves thorough vetting.

• Visible indicators: In some browsers, EV certificates used to display the organization’s name in the address bar, although this is less common now.

• Enhanced trust: Ideal for websites that handle sensitive information, such as financial institutions and e-commerce sites.

Which are more secure?

Extended Validation (EV) certificates are generally considered more secure than Domain Validation (DV) certificates due to the rigorous validation process they undergo. Here’s a comparison:

Domain Validation (DV) certificates

• Validation Level: Only verifies control over the domain.

• Security: Provides basic encryption and assurance.

• Use Case: Suitable for personal websites, blogs, and small businesses.

Extended Validation (EV) certificates

• Validation Level: Verifies the legal, physical, and operational existence of the entity.

• Security: Offers a higher level of trust and assurance due to thorough vetting.

• Use Case: Ideal for financial institutions, e-commerce sites, and any website handling sensitive information.

Why EV certificates are more secure:

• Thorough vetting: EV certificates require extensive validation, making it harder for malicious entities to obtain them.

• Trust indicators: Although less common now, EV certificates used to display the organization’s name in the browser’s address bar, providing visible assurance to users.

• Higher assurance: The detailed verification process ensures that the entity behind the certificate is legitimate, reducing the risk of phishing and other attacks.

What is the process for revocation using OCSP Stapling

OCSP stapling enhances the standard OCSP process by reducing latency and improving privacy. Here’s how it works:

1. Server requests OCSP response: The web server periodically requests the revocation status of its certificate from the OCSP responder (a server maintained by the Certificate Authority, or CA). This request is made in the background and not during each client connection.

2. OCSP responder provides response: The OCSP responder sends back a signed and timestamped OCSP response indicating the certificate’s status (e.g., “good,” “revoked,” or “unknown”). The server caches this response.

3. TLS handshake with stapled response: When a client (e.g., a web browser) initiates a connection to the server, the server includes the cached OCSP response in the TLS handshake. This is known as “stapling” the response to the handshake.

This process reduces the need for clients to make separate OCSP requests, thereby improving performance and privacy.

Work in Progress

A hashing algorithm is a mathematical function that converts input data of any size into a fixed-length string of characters, which is typically a sequence of letters and numbers. This output is known as a hash value or digest.

What is a Collision?

A collision in hashing occurs when two distinct pieces of data produce the same hash value using a hashing algorithm12. This can be problematic because the primary goal of a hashing algorithm is to uniquely represent different data inputs.

What is a MAC?

Message Authentication Code (MAC): In cryptography, a MAC is a short piece of information used to authenticate a message and ensure its integrity. It verifies that the message has not been altered and confirms the sender’s identity.

How is a MAC different from an HMAC?

MAC: A general term for a code that verifies message integrity and authenticity, using either block ciphers or hash functions.

HMAC: A specific type of MAC that uses a cryptographic hash function and a secret key, offering stronger security properties.

Collection of the best Gutmann-Articles, Docs and Slidesets

Work in Progress

History

The Microsoft Active Directory Certificate Services (ADCS), sometimes only called "Microsoft CA", is the Certification Authority software built into Windows Server. The software was originally developed at the end of the last millenium and continued to receive some additions for the next ten to fifteen years.

An alternative is Microsoft's SOAP or , which Microsoft calls Web Enrollment and NDES, respectively.

Public CAs use a two (or three) Tier PKI, i.e. the so-called leaf certificate of the end user is issued by an Issuing CA, sometimes called Subordinate CA or Intermediate CA. This Issuing CA is issued by a Root CA. A certificate is trusted when this issuance chain ends in a Root CA trusted by the client.

Internal CAs often use a Single Tier PKI, i.e. the Root CA directly issues the leaf certificates for the end users without an Intermediate CA.

What happens if an Internal Issuing CA is compromised? If you have a separate Root CA, you can revoke the Issuing CA certificate, of course. CRLs of Root CAs are usually valid for 6 or 12 months; even if you issue a new CRL immediately after the Issuing CA certificate is revoked, clients might not fetch a new CRL for months. In this time frame, the attackers can still use the certificates created with the compromised Issuing CA. Thus, the responsible solution would be the same whether you have single or multi-tier PKI: You would remove the Root CA from the devices' trust store. With Intune-, Jamf- or AD-managed devices (probably most other MDMs, too), this is a few clicks and then applies to all online devices in seconds (Intune, Jamf) or hours (AD). In any case much faster than the revocation method! If you have multiple Issuing CAs created by the Root CA, though, you would also invalidate the uncompromised Issuing CAs using this method, so the two-tier PKI would actually make it more difficult to invalidate the compromised CA. You could use OCSP for the Root CA, but then your OCSP responder would be reachable from the internet. If your CA itself was the OCSP responder, it couldn't be an offline CA anymore. If you used a dedicated OCSP responder, this would make the architecture much more complex, with a very limited security benefit.

For Public CAs, it is also a slow and complex thing to push a new Root CA certificate to devices. Usually, this is part of an OS or browser update, so it takes months and years to reach most devices. From a management perspective, it also makes sense for a Public CA to have a separate Root and Issuing CA. But for your Internal CA, it takes just a few minutes to push a new Root CA to all of your managed devices. It is only if you have a very heterogeneous IT landscape that I would recommend the two-tier PKI for an Internal CA. Let's say you have many unmanaged Linux devices or you are using Thunderbird with its separate certificate store or something the like. Otherwise, the two tiers are no real benefit.

The Abstract Syntax Notation One (ASN.1) is a language used to describe data structures. There are some pre-defined base data types like integers or sequences and an author of a protocol or file format can then define custom data types using the basic ones.

DER Encoding

The defines different encodings for data specified as ASN.1. For X.509-related data, the most important encoding is DER, because there is only one way to encode a type; therefore, a hash of the binary DER representation of the type will always have the same value, which is important for example when signing ASN.1-encoded data.

A Certificate Signing Requests (CSR) as defined in PKCS#10 is a file containing a description of a certificate that you would like to acquire from a Certification Authority (CA). It has a similar structure to an X.509 certificate, but it is missing the signature from a CA. Instead, it contains the signature of the certificate requester. It is still a different format, so it is not the same as a self-signed certificate.

It can be binary DER-encoded or PEM-encoded using the "CERTIFICATE REQUEST" label.

In the context of a Public Key Infrastructure (PKI), situations arise where an issued certificate needs to be invalidated. Three primary techniques address this: Certificate Revocation Lists (CRLs), Online Certificate Status Protocol (OCSP), and Short Lifetime Certificates.

CRLs

Historically, CRLs were the standard for PKIs. A Certification Authority (CA) periodically publishes a list of revoked certificates, including serial numbers, revocation times, and reasons.

CRLs are stored on CRL Distribution Points (CDPs), with HTTP being today's by far most common access method. Because CRLs can become quite large, systems cache them.

The CRL validity enables certificate revocation checks without direct CA involvement and CRL caching even ensures availability during CDP outages. However, they suffer from latency in propagating revocations.

OCSP

OCSP provides real-time certificate status checks. It is an HTTP-based protocol, specified in . Clients query an OCSP responder to verify a single certificate’s validity.

It eliminates the need for large CRLs and reduces the latency between revocation of a certificate and the certificate actually becoming invalid everywhere.

It also allows to consider the live status of the certificate subject, like whether the user the certificate was issued for is still listed in some user directory.

Short Lifetime Certificates

Issuing short-lived certificates (e.g., 1-2 weeks, sometimes only a single day) minimizes the impact of compromised keys and avoids the need for revocations.

It requires systems to fetch fresh certificates more frequently and is therefore unusable in some cases.

Whether the revocation latency is better or worse than CRLs depends on the PKI design, but it cannot get as low as OCSP.

The Public Key Cryptographic Standards (PKCS) is a series of important data formats for cryptographic data.

The core challenge when enrolling certificates is how to authenticate the device or user requesting the certificate. With the certificate, the CA confirms that the certificate owner has specific properties and that it has checked their authenticity.

Therefore, one core property of certificate enrollment protocols is how they authenticate the certificate requester. Depending on what the certificate is used for, one or the other protocol is more advantageous.

One additional important property is its practical adoption. The enrollment method or protocol must be supported by both the CA and on the client side for the intended use case.

The most popular enrollment protocols are:

• SCEP

• ACME

• EST

• Microsoft's SOAP

• Manual enrollment on the CA's web page

• Other proprietary protocols

How does a client indicate its trust of a particular root CA?

A client signifies its trust in a particular root Certificate Authority (CA) through a process involving the certificate chain of trust. Here’s how it works:

• Pre-installed root certificates: Most operating systems and web browsers come with a set of pre-installed root certificates from trusted CAs. These root certificates are stored in a trusted root store.

• Certificate validation: When a client connects to a server (e.g., visiting a website), the server presents its TLS certificate. This certificate is typically signed by an intermediate CA, which in turn is signed by a root CA.

• Chain of trust verification: The client verifies the chain of trust by checking if the presented certificate is signed by a trusted root CA. It also checks if the intermediate CAs in the chain are trusted.

• Digital signatures: Each certificate in the chain is digitally signed by the CA above it. The client uses the public key of the CA to verify these signatures, ensuring that the certificates have not been tampered with.

• Trust decision: If the entire chain of trust is valid and leads back to a trusted root CA, the client trusts the server’s certificate. This allows secure communication to proceed.

What is the benefit of intermediate CAs instead of a single root CA?

For Infrastructure PKIs, a single .

How does an intermediate CA acquire its certificate?

An intermediate Certificate Authority (CA) acquires its certificate through a process called cross-signing by a root CA. Here’s how it works:

1. Certificate Signing Request (CSR): The organization that wants to set up an intermediate CA generates a CSR. This CSR includes the public key and identifying information of the intermediate CA.

2. Submission to root CA: The CSR is submitted to a trusted root CA.

3. Verification: The root CA verifies the identity and legitimacy of the organization requesting the intermediate certificate.

4. Signing: Once verified, the root CA uses its private key to sign the CSR, creating the intermediate certificate. This signed certificate links the intermediate CA to the root CA, establishing a chain of trust.

This process ensures that the intermediate CA is trusted by virtue of its connection to the root CA, which is already trusted by browsers and operating systems.

What is a certificate chain? How does it work?

A certificate chain, also known as a chain of trust, is a sequence of certificates that ensures the authenticity and trustworthiness of a digital certificate. Here’s how it works:

• Verification process: When a client (like a web browser) connects to a server, the server presents its end-entity certificate. The client then checks the certificate chain to ensure each certificate is signed by the next certificate in the chain, up to the root certificate.

• Chain of trust: Each certificate in the chain is verified using the public key of the certificate above it. This process continues until the root certificate, which is already trusted by the client.

• Trust establishment: If the entire chain is valid and leads back to a trusted root certificate, the client trusts the end-entity certificate, allowing secure communication to proceed.

This system ensures that the end-entity certificate is legitimate and has been issued by a trusted authority, maintaining the integrity and security of digital communications.

What problem is the Basic Constraints extension trying to solve?

The Basic Constraints extension in a digital certificate addresses the problem of distinguishing between different types of certificates and their roles within a Public Key Infrastructure (PKI). Here’s how it works:

• Certificate Authority (CA) identification: It specifies whether a certificate is a CA certificate or an end-entity certificate. This distinction is crucial because CA certificates can issue other certificates, while end-entity certificates cannot.

• Path length constraint: It can limit the number of intermediate CAs that can exist below this CA in the certificate chain. This helps prevent excessively long certificate chains, which can be inefficient and potentially insecure.

Problems solved:

• Preventing unauthorised certificate issuance: By clearly marking which certificates can act as CAs, it prevents end-entity certificates from issuing other certificates, thereby maintaining the integrity of the PKI.

• Managing certificate chain length: Limiting the path length ensures that the certificate chain remains manageable and secure, preventing potential vulnerabilities associated with long chains

What mechanism(s) does it use to solve these problems?

The Basic Constraints extension in a digital certificate uses the following mechanisms to solve the problems of distinguishing CA certificates from end-entity certificates and managing the certificate chain length:

• CA flag: This flag indicates whether the certificate is a Certificate Authority (CA) certificate or an end-entity certificate. If the flag is set to TRUE, the certificate can be used to sign other certificates, indicating it is a CA certificate. If set to FALSE, it is an end-entity certificate and cannot issue other certificates.

• Path length constraint: This specifies the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path. By setting this constraint, the extension limits the length of the certificate chain, ensuring it remains manageable and secure.

How do these mechanisms work:

• CA flag: When a certificate is issued, the CA flag is set according to the intended use of the certificate. During the certificate validation process, clients check this flag to determine if the certificate can be trusted to issue other certificates.

• Path length constraint: This value is checked during the validation process to ensure that the certificate chain does not exceed the specified length. If the chain is too long, the certificate is considered invalid.

These mechanisms help maintain the integrity and security of the Public Key Infrastructure (PKI) by ensuring that only authorised certificates can issue other certificates and by preventing excessively long certificate chains.

History and Specification

Cisco first invented the Simple Certificate Enrollment Protocol (SCEP). Although there was no standard at the time, it received widespread adoption in MDM systems. Cisco even moved along and designed a successor protocol, Enrollment over Secure Transport (EST), to replace SCEP. Therefore, EST was made a public standard in RFC 7030 much earlier than SCEP, which was standardized in RFC 8894 a lot later, when it was already the de-facto standard for certificate enrollments for MDM systems.

Technology

SCEP is HTTP-based. A SCEP Request is an encrypted and signed sent via a GET or POST request to the SCEP service. The service responds with a SCEP Response, again an encrypted and signed PKCS#7. The request contains a certificate signing request, the response contains the issued .

Authentication

The PKCS#10 request contains a "SCEP Challenge" that authenticates and authorizes the signing request by some out-of-band method depending on the specific SCEP service. There are three kinds of SCEP challenges used in practice today:

Static SCEP Challenge

The simplest possibility is a static passphrase. If the SCEP Challenge in the PKCS#10 matches a pre-defined value stored on the SCEP service, then the certificate will be issued, otherwise the request will be declined. The problem with this method is that almost no check is possible as to whether the requested properties of the certificate match the requestor. There is even a CVE for this problem.

These methods can be further differentiated:

1. In the case of a Direct SCEP enrollment, the entity to which the certificate shall be enrolled communicates directly with the SCEP service. For example, an MDM system tells some Android phone to do a SCEP enrollment using the SCEP Challenge "SecurePassword". The Android phone generates a CSR, hopefully with the right values, and adds "SecurePassword" as the SCEP Challenge. It then sends the CSR over to the SCEP service, receiving the issued certificate in return.

2. A Transparent SCEP Proxy is just like an HTTP Reverse proxy. Because SCEP is encrypted and signed, it cannot actually look into the SCEP requests or responses or even modify them, but it can control who can enroll certificates and when based on network perimeters.

3. A Protocol Adapter SCEP Proxy is a system that requests certificates through SCEP on behalf of some other system. For example, an MDM system like JAMF could request a certificate from a SCEP service on behalf of some iPhone. Once it has the certificate and private key, it can deploy the certificate through another protocol. This way, only the MDM system has access to the SCEP Challenge, and it can also control the contents of the certificate.

Dynamic SCEP Challenge

In this case, each SCEP Challenge is valid only for a single certificate request. This allows the SCEP service to identify the SCEP request and verify that the requested certificate properties match those permitted for the specific request.

There are generally two ways used in practice how an MDM system and a SCEP CA may agree upon a SCEP Challenge used for a request:

1. The MDM system requests a One-Time-Code for a SCEP Request from the SCEP service if it needs one.

   1. An example is Microsoft NDES. NDES features a separate "admin" page that is authenticated with AD credentials. On each access of the admin page, it creates and displays a new one-time-code that can be used for a single SCEP request. When used in this configuration, NDES does not check any properties of the certificate, though, as the one-time-code is generic.

2. The MDM system generates a one-time-code when it tells a managed system to request a certificate via SCEP. When the SCEP Request arrives at the SCEP Service, the service must fetch the one-time-code from the MDM system, usually with a web hook, and check whether it matches the SCEP Challenge in the request. There is no standard for this protocol, so MDM system and SCEP Service must agree on some format and it depends on the implementation if any properties of the request are checked.

Signed Metadata

There is virtually no length restriction on the SCEP Challenge. So it doesn't have to be a human-comprehensible "passphrase", but it can also be a BLOB.

Intune uses a signed and encrypted XML as the SCEP Challenge. It creates this XML server-side and sends it to a client device when it wants to enroll a certificate and creates the SCEP Request.

The SCEP Service must send the whole PKCS#10 request to an Intune SCEP Challenge service. The SCEP Challenge service has the private key to decrypt the XML and the public key to check that it was create by a genuine Intune service.

The XML contains metadata about the request like how the Subject is supposed to look like. This is derived on the one hand from the SCEP Configuration Profile and on the other hand on the specific object data of the user or device for whom the certificate shall be issued.

For example, the SCEP Configuration Profile might configure CN={{DeviceId}} for the subject. When the device with id xyz requests a certificate, the XML then says that the subject should be CN=xyz. The SCEP Challenge service then compares the information from the XML with the subject in the PKCS#10 request. It will fail the validation if the subjects differ, and it will succeed if this and the other properties match.

The SCEP Service will only issue the certificate if the validation succeeds.

Microsoft features explaining this verification.

Microsoft NDES supports this with an additional NDES Policy Module, other SCEP CAs may or may not support this natively.

Adoption

SCEP is the de-facto standard for MDM systems. All important MDM vendors support SCEP, e.g. Microsoft Intune, Jamf, Mosyle, and Kandji. Adoption among CAs is also common, for example Microsoft ADCS can support SCEP through their NDES service for an on-prem implementation. offers a cloud-only implementation.

X.509 is the standard for digital certificates. There used to be some competitors like OpenPGP, but they are much less frequently used nowadays. But wait ... X.509 isn't actually the right standard. X.509 is actually an ITU-T standard, while the definitions that really matter are actually part of RFC 5280, i.e. a standard from the IETF and not ITU-T. The RFC defines the "PKI Profile for the Internet" based on X.509, but it is the only profile that really matters in practice.

A digital certificate makes use of asymmetric cryptography and especially digital signatures. The most common use case for digital certificate today is server authentication. Everybody has used them already - probably mostly without knowing that it was an X.509 certificate: Every time you access an HTTPS web site, the browser establishes a TLS connection to the web server. The web server uses an X.509 certificate to prove who it is. For example, when people access their bank's website to transfer some money from their bank account, they want to be sure that it is actually their bank they are communicating with. Attackers might try to impersonate the bank website, read the user's password and TAN and then transfer the money a bank account they control. The HTTPS helps prevent this, because the attackers do not have the X.509 certificate of the bank's web server. When the browser says you are accessing a specific domain and it is a HTTPS connection, the certificate makes sure you are really connected to a web server of somebody owning that domain.

How does the certificate do that? The certificate contains some meta data, the public key of a cryptographic key pair, and a signature by a Certification Authority. Let's go through the three parts:

Contents of an X.509 Certificate

Metadata

The metadata of the X.509 certificate for which time it is valid, what the certificate shall be used for, and to whom the certificate was issued, among other things. Especially, for a TLS server certificate, it contains the domain of the web server. The browser compares the domain it tried to access with that in the certificate. If they do not match, the browser will not continue, but display a warning. If the certificate has expired, it will also display a warning.

Strangely, browsers often did not display a warning if you accessed an HTTP site without TLS, although this is even less secure. If you accessed a web server with an invalid X.509 certificate, it may just be a misconfiguration and you might actually be secure from attackers spying upon your connection, while the HTTP connection provides no protection at all.

There is some progress for this issue, though, for example Certificate Pinning. But that's an advanced topic, so let's look at the other two things present in an X.509 certificate.

Public Key

The certificate contains the public part of an asymmetric key pair. The cryptography allows the web server (or generally, the certificate holder if it is a different use case) to prove that it also possesses the private part of the key pair while not exposing it to the connecting client or anybody else. Thus, the client can be sure that the web server is actually the owner of the certificate and not just somebody who copied it. Copying the certificate itself is actually fairly easy, as the web server sends a copy of it to everybody who attempts to connect to the server. Stealing the private key is difficult or impossible, as it never leaves the web server. There are various methods to make stealing the private key more difficult like HSMs and TPMs.

Signature by a Certification Authority

The metadata allows the client to check that the certificate is suitable for the specific use case. The Public key shows that the other party is actually the owner of the certificate. But an attacker might just create a new key pair and a new certificate that also fulfil these two criteria. How would a client know that the certificate is trustworthy?

The certificate contains a cryptographic signature by another key pair that belongs to a Certification Authority (CA) certificate. The CA certificate can be checked in the same way and is also signed by a certificate. The client can follow this "trust chain" from the so-called leaf certificate to the Root CA certificate, which it can recognize by the fact that it is self-signed, i.e. the certificate's signature is from its own key pair. Usually, this is only one or two steps, so there is only one or two CA certificates involved.

CAs must carefully check that the metadata is correct when they . For example, if you want to have TLS server certificate for your own domain, you must prove to the CA that you are really the owner. Depending on how thorough this check is, you get a basic or Extended Validation (EV) certificate.

Each browser and operating system comes with a list of pre-defined Trusted Root CAs. User and/or admins can add additional Trusted Root CAs. Some Root CAs are trusted only for specific purposes, others have a more general trust. The client checks whether the trust chain terminates in a Trusted Root CA. If it does, and all certificates in the trust chain are still valid and the metadata says that they are used according to their purpose, the leaf certificate of the web server is trusted and the connection is established.

Validity of X.509 Certificates

X.509 Certificates are all about trust that must be established. As explained, one criterion for trust is that a certificate must chain up to a Trusted Root CA. Another one is that it is within its validity period. That usually means it is not expired, but -- usually due to technical errors -- a certificate might not be valid yet. But there is one more criterion: The CA issuing the certificate must not have revoked it. Because this is a topic for itself, we have a about it.

PKCS#12 is also known as PFX, especially in Windows environments. Common file endings are therefore .pfx and .p12. It contains X.509 certificates and almost always corresponding private keys, although that is actually not technically enforced.

Data in a PKCS#12 file is usually encrypted to passwords. Often, only the private key is encrypted, so you could extract the certificates without knowing the passwords if your application allows it (most of them do not). While PKCS#12 is the most common way in Windows environments to store a certificate and its private key in a file. In Linux environments, PEM-encoded PKCS#8 files are more common.

Because the standard provides many options how to store certificates and private keys in nested "safebags", PKCS#12 files have some compatibility problems, like:

• Windows is renowned for associating private keys in PKCS#12 with all certificates extracted from the file, not just the one it is meant for. If the PKCS#12 contains a certificate chain, Windows might display that it has the private key for the CA certificate.

What is the general process for message signing?

Message signing is a cryptographic process used to verify the authenticity and integrity of a message.

1. Hash creation: The sender generates a unique digital fingerprint (hash) of the message using a cryptographic hash function (e.g., SHA-256). This hash uniquely represents the message’s content.

2. Signing: The sender encrypts this hash with their private key, creating the digital signature. This ensures that the signature can only be generated by someone with access to the sender’s private key.

3. Sending: The digital signature is attached to the message, and both are sent to the recipient. The sender’s public key is also provided for verification.

4. Verification: The recipient uses the sender’s public key to decrypt the digital signature, retrieving the original hash.The recipient then generates a new hash from the received message and compares it with the decrypted hash. If they match, it confirms that the message has not been altered and verifies the sender’s identity.

What are the three functions of asymmetric encryption?

Asymmetric encryption, also known as public-key cryptography, serves several important functions in securing communications and data.

1. Encryption and decryption

2. Digital signatures

3. Key exchange

RSA

RSA, short for Rivest-Shamir-Adleman, is a widely used public-key cryptosystem for secure data transmission. It was named after its inventors, Ronald Rivest, Adi Shamir, and Leonard Adleman, who introduced it in 1977.

Diffie-Hellman

The Diffie-Hellman key exchange is a method used in cryptography to securely exchange cryptographic keys over a public channel. It was developed by Whitfield Diffie and Martin Hellman in 1976. The main purpose of the Diffie-Hellman key exchange is to enable two parties to securely develop a shared secret key that can be used for encrypting subsequent communications.

Digital Signature Algorithm (DSA)

The Digital Signature Algorithm (DSA) is a public-key cryptographic algorithm used to generate and verify digital signatures. It was proposed by the National Institute of Standards and Technology (NIST) in 1991 as part of the Digital Signature Standard (DSS).

How it Works

1. Key Generation: DSA generates a pair of keys: a private key for signing and a public key for verification.

2. Signing: The sender uses their private key to create a digital signature on a message. This signature is unique to both the message and the private key.

3. Verification: The recipient uses the sender’s public key to verify the authenticity of the signature and, consequently, the integrity and origin of the message.