PKI Signing Requests And Certificate Issuance For Network Authentication
In a PKI (Public Key Infrastructure) system, proof of identity and ownership of key pairs must be verified before the issuance of a digital certificate (X.509) using asymmetric cryptography. A request is sent by an applicant to a CA (Certificate Authority) in order to obtain a digital certificate. Once the identity has been authenticated by a CA, the applicant is issued a digital certificate. This also authorizes the applicant as a member of the network or ecosystem. This gives members the rights and privileges to transact, store and share data. The certificate acts as part of the member’s digital identity.
A digital identity can represent an individual, organization, application or device through the issuance of a digital certificate. The digital certificate contains verified attributes of that representation, which proves the ownership of that identity. These attributes can also contain data that makes up Personally Identifiable Information (PII). The certificate issued by a CA provides authentication, authorization and trust for the digital identity. This provides a way to secure a system against non-members, so it is a trusted and permissioned system. The certificates must be valid for that particular system or else users will not be granted access to any of its resources.
Key Pair Generation
The process begins with the key pair generation. Generating a key pair creates a private key and a public key. The public key is derived from the private key, and is used to create a public address that is exposed in a user’s digital identity. The public address is also associated with a user’s digital wallet or mailbox in a PKI network. A holder must keep their private key secret, but can share their public address and public key information. Knowing the public key and public address does not reveal the private key to other users.
The private key is used for signing digital signatures which prove the ownership or identity of the user on the network. It is also used for decrypting messages sent to a user, which used their public key for encrypting the message. This is unique, and if a user loses their private key they will not be able to sign or decrypt messages. A private key can also be stolen and used maliciously by hackers to steal data, so it is very important to store it safely.
OpenSSL using the genrsa command generates an RSA private key file. In the example below (for Linux and Mac), a private key is generated using the RSA encryption algorithm using a 2048-bit key length. The key is saved to a file <name>.key on your current working directory.
$ openssl genrsa -out <name>.key 2048
Signing Request
The next step requires the CSR (Certificate Signing Request) by an applicant. The information contained in a CSR are data attributes about the user which are labeled under DN (Distinguished Names). This can include the user’s name, e-mail address, town or city, country and organizational unit. The data stored in the CSR must be signed by the applicant’s private key and should also contain their public key information. If the CA receiving the CSR requires more information it must also be included with the request.
There are 3 main parts to a request:
- Certification Request Information — The user’s data and public key (ASN.1 CertificationRequestInfo)
- Signature Algorithm Identifier — Identifies the type of signature algorithm used (signatureAlgorithm e.g. RSA, ECDSA, DSA)
- Digital Signature — Proves the ownership to the public key in the request.
The most common format used for encoding a CSR is PKCS (Public Key Cryptography Standards) #10. When the CA receives the request it parses the data and validates the applicant as the owner of the public key based on their digital signature. After a process by the CA verifies the authenticity of the applicant, the CA then issues a certificate to the user which is signed by the CA’s own digital signature.
The following is an example CSR creation:
$ openssl req -new -key <name>.key -out <name_of_csr>.csr -subj "/CN=<username>/O=<organization_name>"In the CSR, we send the request using a user private key to generate a “.csr” file with the “-subj” parameter that defines a CN (Common Name) and O (Organization).
The following is an example of the contents in a CSR file:
-----BEGIN CERTIFICATE REQUEST-----
MIICaTCCAVECAQAwJDEQMA4GA1UEAwwHc3R1ZGVudDEQMA4GA1UECgwHbGVkcm5l
cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPEIHprZ4FSG7Km0Cj+S
n22hUTRqibiQxsJSRAfwh3dukdclVqxZ7zne0E8oLcgilWOKl9zbgQAhwqTYAvSm
xoyQvG5Uzdv7dsRzKiQH3LHCJT26OXV9g7rAg4WlGwuH85XUwPb2F6006ZYB1T6F
Phj3o0UOoBMlZUq8m6xLA9RY3LDGk6K0wdIFV+7Y7DpAEVxaT3wjSpRGAutuh3j7
icHtbG6NprKNpBRqm6L5MA42Ti070rQaYAbt28H8ipGA9kWnHSwizkZqhJbrs3f0
Ag8o3i0z4ZF/n4QDnF90l+lNVniJGQ75ldJ36beCGm9c5w1R152gkk01lLBTGhBi
As8CAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQBChMWmkg01nsushpr6gkBHb8MM
XL0ASxSNmLC2WGnLHSNtDfYrHW1ofBQZZyNEllUeTKkTQpebWZrtzSpme8qWaGe1
XCjnhlMKYYpD4mz8kv0hW+h6WgDWxq+HfzX2WXLySH8ecwJdlrwG8EutVzi7c/zZ
SwGxZdfOsRr8KfCtZtlBm4pOnG7i9oegimQ8eVDkhi7ZC4Blw1xX6Pzdgl+HWk4i
oA22nqrUAeAbnNe/N5nD4vT++pQnZ8PQcLm3JGfJaZ+Mes09rDw00buWz+GL+ZKe
RjweiEtLvMN4DCz7inCZ7xIhZOftF5LsS/uCZF0RayNb3DgDQopFKlJnmX1g
-----END CERTIFICATE REQUEST-----Encoding And Sending Request
Before sending the CSR, it can be encoded in Base64. Some CA servers do not require this, allowing applicants to send the CSR request by copy and pasting it (enclosed in the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST) to a web-based form. The CSR can be viewed and output to “base64” encoding.
$ cat student.csr | base64 | tr -d '\n'The result will then look like the following:
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ2FUQ0NBVkVDQVFBd0pERVFNQTRHQTFVRUF3d0hjM1IxWkdWdWRERVFNQTSHQTFVRUNnd0hiR1ZoY201bApjakNDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFQRUlIcHJaNEZTRzdLbTBDaitTCm4yMmhVVFJxaWJpUXhzSlNSQWZ3aDNkdWtkY2xWcXhaN3puZTBFOG9MY2dpbFdPS2w5emJnUUFod3FUWUF2U20KeG95UXZHNVV6ZHY5ZHNSektpUUgzTEhDSlQyNk9YVjlnN3JBvTRXbEd3dUg4NVhVd1BiMkY2MDA2WllCMVQ2RgpQaGozbzBVT29CTWxaVXE4bTZ4TEE5UlkzTERHazZLMHdkSUZWKzdZN0RwQUVWeGFUM3dqU3BSR0F1dHVoM2o3CmljSHRiRzhOcHJLTnBCUnFtNkw1TUE0MlRpMDcwclFhWUFidDI4SDhpcEdBOWtXbkhTd2l6a1pxaEpicnMzZjAKQWc4bzNpMHo0WkYvbjRRRG5GOTBsg2xOVm5pSkdRNzVsZEozNmJlQ0dtOWM1dzFSMTUyZ2trMDFsTEJUR2hCaQpBczhDQXdFQUFhQUFNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUJDaE1XbWtnMDJuc3VzaHByNmdrQkhiOE1NClhMMEFTeFNObUxDMldHbkxIU050RGZZckhXMW9mQlFaWnlORWxsVWVUS2tUUXBlYldacnR6U3vtZThxV2FHZTEKWENqbmhsTUtZWXBENG16OGt2MGhXk2g2V2dEV3hxK0hmelgyV1hMeVNIOGVjd0pkbHJ3RzhFdXRWemk3Yy96WgpTd0d4WmRmT3NScjhLZkN0WnRsQm00cE9uRzdpOW9lZ2ltUThlVkRrSGk3WkM0Qmx3MXhYNlB6ZGdsK0hXazRpCm9BMjJucXJVQWVBYm5OZS9ONW5ENHZUKytwUW5aOFBRY0xtM0pHZkphWitNZXMwOXJEdzAwYnVXeitHTCtaS2UKUmp3ZWlFdEx2TU40REN6N2luQ1o3eEloWk9mdEY1THNTL3VDWkYwUmF5TmIzRGdEUW9wRktsSm5tWDFFCi0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=A YAML file can be created with an encoded certificate request into the “request” field. This creates a certificate signing request object to be sent to the CA server. There is no one template for creating a YAML file. It will depend on what you are requesting from the CA server.
request: <assign the encoded value here>However way you sent the request, by YAML or via a web form, when the CA server receives the request it will parse the data to perform an integrity check. Once the CA verifies the digital signature and public key, it then authenticates the applicant. The CA then issues a digital certificate to the user that is signed with the digital signature of the CA server.
Applications
Digital certificates are issued by CA servers for different purposes. It can be to issue or renew an SSL certificate for a public web server. It can also be used for authenticating digital identities used in a permissioned network that must verify a user’s identity. When it comes to e-mail encryption, e-signatures and code signing the digital certificate is authenticating a user. For TLS/SSL the authentication is for web servers or other devices. The PKI provides the system to create, store and distribute digital certificates for authentication on a network.
