[P]Delete

# OpenSSL root CA configuration file. # Copy to `/root/ca/openssl.cnf`. [ ca ] # `man ca` default_ca = CA_default [ CA_default ] # Directory and file locations. dir = /root/ca certs = $dir /certs crl_dir = $dir /crl new_certs_dir = $dir /newcerts database = $dir /index.txt serial = $dir /serial RANDFILE = $dir /private/.rand # The root key and root certificate. private_key = $dir /private/ca.key.pem certificate = $dir /certs/ca.cert.pem # For certificate revocation lists. crlnumber = $dir /crlnumber crl = $dir /crl/ca.crl.pem crl_extensions = crl_ext default_crl_days = 30 # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 name_opt = ca_default cert_opt = ca_default default_days = 375 preserve = no policy = policy_strict [ policy_strict ] #...

Online Certificate Status Protocol The Online Certificate Status Protocol (OCSP) was created as an alternative to certificate revocation lists  (CRLs). Similar to CRLs, OCSP enables a requesting party (eg, a web browser) to determine the revocation state of a certificate. When a CA signs a certificate, they will typically include an OCSP server address (eg,  http://ocsp.example.com ) in the certificate. This is similar in function to  crlDistributionPoints  used for CRLs. As an example, when a web browser is presented with a server certificate, it will send a query to the OCSP server address specified in the certificate. At this address, an OCSP responder listens to queries and responds with the revocation status of the certificate. Note It’s recommended to use OCSP instead where possible, though realistically you will tend to only need OCSP for website certificates. Some web browsers have deprecated or removed support for CRLs. Prepare the con...

Certificate revocation lists A certificate revocation list (CRL) provides a list of certificates that have been revoked. A client application, such as a web browser, can use a CRL to check a server’s authenticity. A server application, such as Apache or OpenVPN, can use a CRL to deny access to clients that are no longer trusted. Publish the CRL at a publicly accessible location (eg, http://example.com/intermediate.crl.pem ). Third-parties can fetch the CRL from this location to check whether any certificates they rely on have been revoked. Source: https://jamielinux.com/docs/openssl-certificate-authority/certificate-revocation-lists.html Note Some applications vendors have deprecated CRLs and are instead using the  Online Certificate Status Protocol (OCSP) . Prepare the configuration file When a certificate authority signs a certificate, it will normally encode the CRL location into the certificate. Add  crlDistributionPoints  to the appropriate sec...

Sign server and client certificates We will be signing certificates using our intermediate CA. You can use these signed certificates in a variety of situations, such as to secure connections to a web server or to authenticate clients connecting to a service. Note The steps below are from your perspective as the certificate authority. A third-party, however, can instead create their own private key and certificate signing request (CSR) without revealing their private key to you. They give you their CSR, and you give back a signed certificate. In that scenario, skip the  genrsa  and  req  commands. Create a key Our root and intermediate pairs are 4096 bits. Server and client certificates normally expire after one year, so we can safely use 2048 bits instead. Note Although 4096 bits is slightly more secure than 2048 bits, it slows down TLS handshakes and significantly increases processor load during handshakes. For this reason, most websites use 2048-...

Create the root pair Acting as a certificate authority (CA) means dealing with cryptographic pairs of private keys and public certificates. The very first cryptographic pair we’ll create is the root pair. This consists of the root key ( ca.key.pem ) and root certificate ( ca.cert.pem ). This pair forms the identity of your CA. Typically, the root CA does not sign server or client certificates directly. The root CA is only ever used to create one or more intermediate CAs, which are trusted by the root CA to sign certificates on their behalf. This is best practice. It allows the root key to be kept offline and unused as much as possible, as any compromise of the root key is disastrous. Note It’s best practice to create the root pair in a secure environment. Ideally, this should be on a fully encrypted, air gapped computer that is permanently isolated from the Internet. Remove the wireless card and fill the ethernet port with glue. Prepare the directory Choose a directory ...