X.509 digital certificates use the X.509 Public Key Infrastructure (PKI) to certify a public key to a user, device, or service identity embedded in the certificate. A PKI encapsulates the framework to use a certificate signing request (CSR) and enables users and servers to generate digital certificates like a TLS/SSL certificate.
In a PKI, a certificate signing request (CSR) is a message sent to the certificate authority to get a digital certificate. A certificate signing request (CSR) contains information like the public key, domain name, and the corresponding signatures needed to generate a certificate.
Read on to learn about CSR generation, the process of generating a certificate in the JoinNow Connector PKI, and see how our vendor-neutral PKI makes shifting to certificate-based authentication easy.
What Is a Certificate Signing Request?
A PKI contains the framework for a certificate signing request (CSR), which helps users and servers obtain SSL and TLS certificates. A CSR is sent to the certificate authority to obtain a digital certificate. Signing certificates starts with the client generating a key pair known as the private and public keys. The key is then signed with the private key and sent to the certificate authority to generate a digital certificate. Upon verification, the CA sends the certificate to the applicant. A certificate can contain the following:
- Fully qualified domain name
- Legal Name of an Organization
- Organization unit
- City/State
- Country
- Email ID
- The public key for which the certificate is to be issued
- Unique identifying name
- Proof of authenticity. e.g., digital signature. The Certificate Signing Requests (CSR) follow the Public Key Cryptography Standard #10 (PKCS #10), the format used to send a message to certify a public key.
Image Courtesy: Medium
Structure of a Certificate Signing Request (CSR)
A Certificate Signing Request consists of three main parts:
- Certification Request Information that contains pertinent information like the public key
- Signature Algorithm Identifier
- Digital Signature Identifier
The CSR must also provide the email ID of the user or the organization if it is for a business entity.
A PKCS#10 in ASN.1 format for CSR:
The Public Key Cryptography Standard #10 (PKCS #10) stands for certificate signing request (CSR) syntax. It is a security standard produced and distributed by RSA Data Security Inc. and consists of a name, public key, and set of attributes.
The Abstract Syntax Notation.1 (ASN.1) is a notation describing the data transmitted by a telecommunication protocol. The ASN.1 transmits information in any form to anywhere and covers the structural information.
Here is the syntax of how a PKCS#10 CSR is generated in an ASN.1 format
ASN.1 type CertificationRequestInfo, consists of a version number, the subject name, public key (algorithm identifier + a bit string), and additional attributes about the purpose of the certificate.
The attributes include extensions, a challenge password to curtail revocations, and other information like the subject and the types of certs (local or future).
The Process of Certificate Signing Requests & Generating a Private Key
SSL certificates and other types of certificates follow a similar CSR process. The process is as follows:
- The applicant generates a key pair, i.e., the private and the public key.
- The applicant places the private key securely, such as a hardware crypto device like a USB or a token or software like Windows Key Store, Mac Keychain, etc.
- Then, they generate a PKCS#10 structure which contains the subject, the public key generated in the above step, and additional attributes.
- Next, the applicant signs the PKCS#10 private key generated above.
- CA receives PKCS#10 and sends a standard request/response protocol (CMP, CMC, EST, SCEP, XKMS, CA proprietary interface, etc.) or PKCS#10 to CA using the SMTP protocol.
- CA verifies the signature with the public key.
- Upon successful signature verification, it is proven that the applicant possesses the corresponding private key.
- CA sends the certificate and the certificate chain to the applicant.
Explaining the Certificate Trust Chain To Establish Certificate Authority
A Trust Chain is the specific order in which certificates are issued in a PKI.
A secure certificate chain begins with a root certificate issued by the CA and is followed by one or more intermediate certs. Lastly, the end certificate is issued, known as the Trust anchor.
Here’s a diagram illustrating the certificate chain and its aspects:
Root Certificate:
The first certificate issued by a CA in a trust chain is the Root certificate. Known as a trusted root, the Root certificate is endorsed by a trusted CA and is a step before issuing intermediate CAs. Root certificates are obtained from the root stores. Devices contain root stores that are native to their operating system.
A root certificate must be secured well. Otherwise, the transmission would need to be improved. To utilize the Root certificate effectively, they are preloaded in internet browsers and on devices existing on a network.
Intermediate Certificate:
An intermediate CA connects the root CA and the user to obtain an end-user certificate. CAs cannot issue certificates from their root store. Thus, a CA uses Root certificates to sign and issue intermediate certificates. These are used to issue end-user certificates in the final step of the trust chain.
A CA’s verification protocols function to protect the Root certificate. Thus, intermediate certs are issued to secure the protocol, helping to prevent the Root certificate from getting revoked.
End-User Certificate:
A Root CA does not produce end-user certificates. Intermediate CAs get certificates from the Root CA and are used to sign end-user and server certificates. Numerous intermediate CAs can be configured between the Root and end-user certificates, thus giving rise to the Trust Chain.
How Does a Browser Authenticate SSL/TLS Certificates?
A website sends its SSL/TLS certificate to a browser to authenticate its web pages. The browser checks the following:
- The integrity of the certificate as per its digital signature to prove that it originated from a legitimate server.
- Validity to ensure the certificate is still active.
- Revocation status from the Certificate Revocation List (CRL).
Upon verification, the browser and server initiate a TLS handshake to encrypt the connection. This ensures no malicious threat actors can get access, and the user can safely access the webpage.
How to Obtain a User Certificate From Our JoinNow PKI
- Log in to our JoinNow Management portal with your credentials.
- Hover over “PKI” and select “Create Certificate.”
3. Enter the device information, i.e., the OS (Windows, Mac, etc.), a user description, and the device’s MAC address.
4. Scroll down to the “Certificate” section and enter the CA, common name, validity, override validity, and select Generate keypair and CSR. Then, enter the details as shown here
5. As you scroll down, enter your email address, URL, and other names (email ID) under the “SAN.” Then, select “Client Authentication” under the “Extended Key Usage” header.
6. Finally, select the certificate template name, policies, and your preference to receive the PKCS and click “Create.”
7. The CA will generate a user certificate, which you can use immediately.
Vendor-Neutral PKI for CSRs and CA Generation
A trusted certificate authority is crucial to issuing digital certificates in a network. A trusted root CA signs impending intermediate CAs that go on to issue end-user and server certificates. This establishes a trust chain that protects the root certificate from any breaches.
Click here to see how our customers adapted to digital certificates with our Managed PKI.
A trusted CA can be obtained from a PKI, and SecureW2s managed PKI is a solution to all your needs. Our vendor-neutral PKI provides a turnkey solution for all your managed devices in the network. The solution is straightforward and can be set up in no time.
Head over here to try our solutions and secure your network right away.
