Types of certificates

In this section, we explain the function of the root CA certificate.

Root CA (Certificate Authority) certificates are at the top of the hierarchical structure of digital certificates used in the public key infrastructure (PKI). A Root CA is a highly trusted entity that issues digital certificates to intermediate CAs (Certificate Authorities) or directly to end entities such as the Portnox Cloud. These certificates are then used to verify the authenticity of the entities they certify.

Root CA certificates are pre-installed and trusted by default in web browsers, operating systems, and other applications, and any certificate issued by them is automatically trusted by those systems. However, older systems may not have all the root CA certificates, such as the DigiCert Trusted Root G4 used by Portnox Cloud. That is why Cloud provides you with this CA certificate to download and install on such systems.

If your system is old and it does not have the DigiCert Trusted Root G4 CA certificate installed, it will not be able to verify the identity of the cloud RADIUS server, which will generate warnings, and in some systems it can even prevent you from using Portnox Cloud.

You can download the DigiCert Trusted Root G4 certificate here: Settings > Services > CLEAR RADIUS SERVICE > CLEAR RADIUS instance > Europe and Asia or United States and North America > Download root certificate, or directly from our documentation server, or directly from DigiCert.

In this section, we explain the function of the cloud RADIUS certificate.

The cloud RADIUS certificate is signed using the root CA certificate. Portnox purchases this certificate annually from DigiCert to guarantee the authenticity of its RADIUS servers, which use the domain name clear-rad.portnox.com.

If you need to use the RADIUS server certificate for any purpose, contact us at support@portnox.com to receive the certificate file.

In this section, we explain the function of the SCEP server’s intermediate certificate.

You can use the Portnox Cloud SCEP (Simple Certificate Enrollment Protocol) server to request certificates for your devices. The SCEP protocol works through HTTP/HTTPS requests and is mainly used by UEM (Unified Endpoint Management) and MDM (Mobile Device Management) solutions.

Most device operating systems, such as Windows, macOS, and iOS, by default use SCEP via HTTP requests. However, some device operating systems such as Android require SCEP via HTTPS requests. To make such requests, the devices must have the SCEP server’s intermediate certificate to validate the SCEP server’s identity.

The Portnox Cloud SCEP server’s intermediate certificate is the Thawte TLS RSA CA G1 certificate. In many cases, the operating system of the device already has this standard certificate installed, and you don’t need to upload it to the device. However, it is safer to distribute the certificate using your UEM/MDM solution to make sure that every device can connect using SCEP via HTTPS.

If you need to use the SCEP server’s intermediate certificate to your UEM/MDM software configuration profiles, you can download it directly from our documentation server. Alternatively, you can download it from the DigiCert website.

In this section, we explain the function of the tenant CA certificate.

The tenant CA certificate is a root certificate, which means that it has no chain of signatures. It is completely independent of the root CA certificate. The tenant CA certificate is a self-signed certificate for the tenant-specific CA that is used by Portnox Cloud to authenticate your users and devices, and you should not use it for any other purpose.

If your organization has its own certificate authority and you want to use this CA to generate user and device certificates, you can replace the default tenant CA certificate generated by Portnox Cloud with your own CA certificate. Then, you will need to use your own CA to generate device/user certificates, and Cloud will use the uploaded tenant CA certificate to confirm if they are genuine and use them to verify users/devices.

You can download the tenant CA certificate or upload your own CA certificate here: Settings > Services > GENERAL SETTINGS > Trusted Root Certificates.

In this section, we explain the function of the user and device certificates, also known as supplicant certificates.

The user/device (supplicant) certificates are signed by the tenant CA, so they have the tenant CA certificate as the root of their signature chain. This can be either the default tenant CA provided by Portnox Cloud or your own CA.

• If you use the default tenant CA provided by Portnox Cloud, you can have Cloud generate all user and device certificates for you. This is possible because then Cloud has access to the certificate’s private key, which is needed to sign other certificates. You can, for example, ask your users to use the self-service onboarding portal to generate and download these certificates for their devices.

• If you use your own CA that you uploaded to Portnox Cloud, then Cloud cannot generate user/device certificates because it does not have the private key. Only you have the private key because it is your certificate authority. You have to generate all user/device certificates yourself and distribute them to your users’ devices, for example, using unified endpoint management (UEM) solutions such as Intune.

In this section, we explain the common certificate formats used in Portnox Cloud and during onboarding.

All of the certificates mentioned above can be saved in various formats. In some cases, such as with endpoint management systems, you might need to convert your certificate to a different format. The three most common formats used in Portnox Cloud and onboarded devices are:

• Base-64 encoded X.509 / Privacy-Enhanced Mail (PEM): This is the most common format for X.509 certificates, which is a Base-64 encoded text file. To check if your certificate is in this format, you can simply open it in a text editor. If you see the BEGIN CERTIFICATE header, it means the certificate is in the PEM format. This format is sometimes called Privacy-Enhanced Mail, because it was originally developed to secure email communications.

  Note that despite the name of the format, PEM certificates are very often stored with the .crt or .cer extension, which are also used by the DER format described below, instead of the .pem extension. Some systems will even reject PEM certificates with the .pem extension. Therefore, you should not use the extension to determine the format of the file.

• X.509 DER encoded binary: This is the binary format of X.509 certificates that is also commonly used. The certificate is stored in the DER (Distinguished Encoding Rules) format, which is part of the X.690 standard.

  Note that despite the name of the format, DER certificates are very often stored with the .cer or .crt extension, which is also used by the PEM format described below, instead of the .der extension. Some systems will even reject DER certificates with the .der extension. Therefore, you should not use the extension to determine the format of the file.

  The rootCertificate.cer file available in Portnox Cloud for the root CA certificate is in the X.509 DER encoded binary format.

• PKCS #12: This is an archive file format for storing many cryptography objects in a single file. It is often used to combine the X.509 certificate with its corresponding private key, or to bundle all the members of the chain of trust. Many systems do not accept this format and you may need to convert the certificate to one of the two previously mentioned formats. Systems that accept the PKCS #12 format often do not accept private keys with empty passwords.

  The most common extension for PKCS #12 files is .pfx but the extension .p12 is also used.

  The file available in Portnox Cloud for the tenant CA certificate is in the PKCS #12 format bundled with the corresponding private key, which has an empty password.

• PKCS #7: This is a standard commonly used to bundle multiple certificates together, for example, to include a certificate and its chain of trust. This format does not store private keys.

  The most common extension for PKCS #7 files is .p7b or .p7c.

  In Portnox Cloud, you can use this format to import your own CA certificate as the tenant CA certificate together with any intermediate certificates if you use them to sign the supplicant certificates.

In this section, we explain whether certificates generated by Portnox Cloud for users/devices can be copied to other devices.

When Portnox Cloud generates a certificate for the user or device, and then AgentP or the user installs that certificate on a device, it is actually not just the certificate but a certificate-key pair: private key and the corresponding certificate (public key). Both parts are needed for authentication.

The certificate (public key) can always be exported. However, operating systems allow the users and applications to install the private key as exportable or non-exportable.

• If the private key is exportable, it means that you can export it to a file.

• If a private key is non-exportable, it means that you cannot export it to a file and, for example, copy to another device.

This means that if the private key is installed as non-exportable, you cannot copy it to any other device. For example, you cannot export it from the device’s operating system and upload to another device. If you export and copy just the certificate, without the private key, authentication will not work.

In this section, we explain why configurations optionally ask for a trusted certificate server name.

When you select the certificate to verify the authenticity of the cloud RADIUS servers, either in your operating system or in an UEM solution, you usually also have an option to trust a specific domain name. This option may be called Connect to these servers (in Windows), Certificate server names (in Intune), Trusted certificate server names (in macOS/iOS/Jamf) or Server Certificate Names (in Kandji).

This is an optional, extra security measure. Is not necessary, but it is recommended. It means that your operating system or your UEM software, once it verifies the validity of the certificate, checks who the certificate was issued to and compares it with the domain name that you provided. In such case, if you provide the domain name clear-rad.portnox.com, your operating system or UEM solution will confirm that the cloud RADIUS server certificate is issued to this domain name (by checking the certificate’s Subject field), which adds an extra layer of security.

In this section, we explain the importance of the identity information in the certificate, where such information is stored, and how to change the storage location.

When a supplicant device presents its certificate to the Portnox Cloud RADIUS server (or other Cloud services such as Conditional Access for Applications), Portnox Cloud needs to identify the owner of the certificate. The certificate itself does not inherently contain identifying information, similar to an ID document that cannot have just a fingerprint; it must also include the owner's name for proper identification.

Certificates have special fields that can be used to contain such information and any additional information that is required. The primary field is the Subject field, which is present in every certificate, and is usually filled with some kind of identification information. For example, for website certificates, the Subject field contains the URL of the website. However, there is an option to include more such information in certificates, and it’s called Subject Alternative Names (SAN). SAN is not just one field but rather a whole system of adding extra fields that can contain email addresses, DNS names, and much more. The most common field, used by Portnox Cloud to store the identify information is called the User Principal Name (SAN UPN).

However, if you use your own tenant CA certificates instead of the ones generated by Portnox Cloud, and manage your supplicant certificates using your own CA rather than Portnox Cloud with AgentP or SCEP, you may prefer to store user identity information in a different field within the certificate. In this case, Portnox Cloud provides an option to specify where the RADIUS server should look for user identity information within the certificate: Settings > Services > GENERAL SETTINGS > Define custom user identity source (Advanced).

In this section, you can select more than one field that is to be checked for user identity information, and you can also drag the fields up or down to define the order in which they are to be checked.

In this section, we explain what is certificate revocation and how Portnox Cloud handles certificate revocation.

A certificate can become invalid in two ways:

• If its expiration date passes.
• If it is manually revoked.

The certificate’s expiration date is stored within the certificate itself, so it’s easy for the device’s operating system or an application to compare this date with the current date to determine if the certificate is still valid.

However, if the certificate is manually revoked, this action occurs on the issuer’s side, not on the device. For example, if Portnox Cloud generates a certificate for a device and the administrator later decides to revoke it, this revocation is recorded in Portnox Cloud, not directly on the device.

So, how can the device’s operating system or an application such as AgentP check if the certificate is still valid?

Portnox Cloud supports two methods for this verification:

• CRL: certificate revocation lists

  In this method, the certificate issuer creates a list of all the certificate serial numbers that have been revoked. The operating system can download and view this list over a regular HTTP connection (it can even be opened in a browser) to see if a specific certificate is included. If the certificate is on the list, it is revoked; if it’s not on the list, it is still valid.

  This method is simple and widely supported around the world. However, it has a drawback: if the issuer issues and cancels many certificates (such as thousands each day, like some large enterprises), the list can get very long. This may slow down the download process, making it take longer for the system to check the certificates.

  This is an example of a CRL URL included in a Portnox Cloud certificate:

  

  This is an example of a CRL list (.crl file) downloaded from Portnox Cloud and opened in Windows:

  

• OCSP: online certificate status protocol

  This is a newer method, but it is not as widely supported as the CRL method. With OCSP, each certificate has a specific URL that can be queried to check if it is still valid. When a device needs to check a certificate’s status, it sends a request to this URL with the certificate’s serial number. The server then responds with the current status of that specific certificate.

  Because the OCSP response only covers one certificate, it is much smaller and faster to process than a full CRL file, making it more efficient when many certificates are revoked.

  Note: OCSP requests and responses use a binary format, so they can only be processed by the operating system or certain applications.

  This is an example of an OCSP URL included in a Portnox Cloud certificate:

  

To see how to configure CRL and OSCP in Portnox Cloud, see the following topic: How does Portnox Cloud handle certificate revocation?.