This article has been created to help those required to implement a more secure network using certificates but only have minimal experience working with certificates. It provides a basic understanding of certificate use so you can better implement certificates in your network. This article has been broken down into three categories—knowledge to provide a general understanding of the certificate flow, common tasks used in implementing certificates, troubleshooting, and answers. Reading through these categories will provide you with a basic understanding that will help you with your certificate implementation.
"A public key infrastructure is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption."
Source: https://en.wikipedia.org/wiki/Public_key_infrastructure
In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the ownership of a public key.[1] The certificate includes information about the key, information about the identity of its owner (called the subject), and the digital signature of an entity that has verified the certificate's contents (called the issuer). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.
In a typical public-key infrastructure (PKI) scheme, the certificate issuer is a certificate authority (CA), usually a company that charges customers to issue certificates for them. By contrast, in a web of trust scheme, individuals sign each other's keys directly, in a format that performs a similar function to a public key certificate.
The most common format for public key certificates is defined by X.509.[2] Because X.509 is very general, the format is further constrained by profiles defined for certain use cases, such as Public Key Infrastructure (X.509) as defined in RFC 5280.
"In cryptography, X.509 is a standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. An X.509 certificate contains a public key and an identity (a host name, or an organization, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.
DER is digital certificate encoded in binary and it is used by Windows Systems. Base64 is a DER version of the digital certificate converted to text (ASCII) and it is used by Linux systems. When it comes to reading certificate files, what matter is the content of the file, if it is encoded using DER or Base64 standard. However, you will find that, generally, the file extensions for DER files are .der, .crt, and .cer. For Base64, it is usually .pem.
It is the first member service responsible for signing certificates for intermediate CAs to form a chain of trust
It is the second member service responsible for signing certificates for other intermediate CAs or end entity to form a chain of trust
"Digital certificates are verified using a chain of trust."
X.509 also defines certificate revocation lists, which are a means to distribute information about certificates that have been deemed invalid by a signing authority, as well as a certification path validation algorithm, which allows for certificates to be signed by intermediate CA certificates, which are, in turn, signed by other certificates, eventually reaching a trust anchor. "
With CRLs, the list of revoked certificates is downloaded from a certificate distribution point (DP) that is often specified in the certificate. The server periodically goes to the CRL DP URL specified in the certificate, downloads the list, and checks it to determine whether the server certificate has been revoked.
It is planning for certificates renewal according to rules.
The instructions outlined in this session are focused on Linux systems since CAS Manager, Connector and License server are Linux based server applications.
1 - Create a file with the following content and save is as server.example.com.cnf
[ req ] default_bits = 2048 default_md = sha256 prompt = no encrypt_key = no distinguished_name = dn req_extensions = req_ext [ dn ] C = ST = L = OU = O = CN = #FQDN, DNS Name, . [ req_ext ] subjectAltName = extendedKeyUsage = serverAuth basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment basicConstraints = critical,CA:FALSE
2 - Execute the following command to generate a certificate request file and the private key
openssl req -new -config server.example.com.cnf -keyout server.example.com.key -out server.example.com.csr
3 - Use the certificate request file (.csr) to request a certificate through internal request (your own company) or a third-party certificate provider
4 -Verify the certificate package
You should receive back a certificate package containing the following files:
If the package contains certificates generated by a Windows system, it is possible that the files are DER encoded. So you will need to convert them to Base64.
openssl x509 -in certificatename.cer -outform PEM -out certificatename.pem
Testing for Base64 encoding standard
openssl x509 -in cert.pem -text -noout
If you receive the message below, it means the file is not encoded using Base64
unable to load certificate
12626:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: TRUSTED CERTIFICATE View DER encoded Certificate
Testing for DER encoding standard
openssl x509 -in certificate.der -inform der -text -noout
If you receive the message below, it means the file is not encoded using DER
unable to load certificate
13978:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1306:
13978:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:380:Type=X509
The certificate package may come with the root certificate, and, at least, one intermediate certificate bundled together in the same file.
If you are installing the CA bundle on Ubuntu, you must split the ca bundle file into two files as you can see below.
Individual certificate files (for Ubuntu)
intermediate.pem
-----BEGIN CERTIFICATE-----
Intermediate certificate content
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root certificate content
-----END CERTIFICATE-----
Certificate bundle (for CentOS)
-----BEGIN CERTIFICATE-----
Intermediate certificate content
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root certificate content
-----END CERTIFICATE-----
Copy the ca bundle file into the following folder
/etc/pki/ca-trust/source/anchors/CA-%domain-fqdn%.crt # You can name the file whatever you want here
Update the certificate store
sudo update-ca-trust extract
Create a folder
sudo mkdir /usr/share/ca-certificate/extras #You can name the folder whatever you want.
Copy the ca root and intermediate certificate files into the following folder:
Update the certificate store
sudo apt-get install ca-certificates -y
sudo dpkg-reconfigure ca-certificates
The verify command must return “OK” otherwise something is wrong
openssl verify root.crt
openssl verify inter.crt
openssl verify server.crt # here you should have the server certificate and the private key in the same folder
openssl x509 -noout -text -in server.crt # Server, In this case the connector certificate
openssl x509 -noout -text -in root.crt #Root CA
openssl x509 -noout -text -in inter.crt #Intermediate CA
If the hash generated by the commands below are the same, it means the private key and the server certificates match. Otherwise, you have to find the right private key or generate a new certificate request.
openssl x509 -noout -modulus -in server.crt | openssl md5
openssl rsa -noout -modulus -in server.key | openssl md5
