- Brief
- Certificate Signing Request(CSR)
- Generate a Private Key and a CSR
- Generate a CSR from an Existing Private Key
- Generate a Self-Signed Certificate
- Certificates and Encodings
- Useful Commands
- Keys and SSL Certificates
- Certificate Wildcards and SANs
- Symmetric and Asymmetric Cryptography use case
- TLS handshake
- Client Certificates
Excerpt from Openssl Essentials Blog, SSL Certificates Explained and Dive Deep into TLS.
Secure Sockets Layer(SSL) and Transport Layer Security(TLS) are protocols that provide secure communications over a computer network.
TLS is based on SSL and was developed as a replacement in response to known vulnerabilities in SSLv3. SSL is the term commonly used, and today usually refers to TLS.
The certificate contains the recipient’s identity and public key. This information is then used to encrypt the message.
If you would like to obtain an SSL certificate from a certificate authority(CA), you must generate a certificate signing request(CSR). A CSR consist mainly of the public key of a key pair, and some additional information. Both of these components are inserted into the certificate when it is signed.
Whenever you generate a CSR, you will be prompted to provide information regarding the certificate. This information is known as a Distinguised Name(DN). An important field in the DN is the Common Name(CN), which should be the exact Fully Qualified Domain Name(FQDN) of the host that you intend to use the certificate with. It is also possible to skip the interactive prompts when creating a CSR by passing the information command line or from a file.
Here is an example of what the CSR information prompt will look like:
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:Brooklyn
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Brooklyn Company
Organizational Unit Name (eg, section) []:Technology Division
Common Name (e.g. server FQDN or YOUR name) []:examplebrooklyn.com
Email Address []:If you want to non-interactively answer the CSR information prompt, you can also do so by adding the -subj option to any OpenSSL commands.
-subj "/C=US/ST=New York/L=Brooklyn/O=Example Brooklyn Company/CN=examplebrooklyn.com"Use this method if you want to use HTTPS to secure Apache HTTP or Nginx web server, and you want to use a Certificate Authority(CA) to issue the SSL certificate. The CSR that is generated can be sent to a CA to request the issuance of a CA-signed SSL certificate. If your CA supports SHA-2, add the -sha256 option to sign the CSR with SHA-2.
This command creates a 2048-bit private key(domain.key) and a CSR(domain.csr) from scratch:
~$ openssl req -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr
# -nodes: the private key should not be encrypted with a pass phrase.
# -new: not included here but implied, indicates that a CSR is being generated.Use this method if you already have a private key that you would like to use to request a certificate from a CA.
This command creates a new CSR(domain.csr)based on an existing private key(domain.key):
~$ openssl req -key domain.key -new -out domain.csr
# -key: specifies an existing private key(domain.key) that will be used to generate a new CSR.
# -new: indicates that a CSR is being generated.A common type of certificate that you can issue yourself is a self-signed certificate. A self-signed certificate is signed with its own private key. Self-signed certificates can be used to encrypt data just as well as CA-signed certificates, but your users will be displayed a warning says that the certificate is not trusted by their computer or browser.
~$ openssl req -newkey rsa:2048 -nodes -keyout domain.key -x509 -days 365 -out domain.crt
# -x509: tell req to create a self-signed certificate.
# -days 365: certificate will be valid for 365 days.Encodings
.DER = The DER extension is used for binary encoded certificates. These files may also bear the CER or CRT extension. Proper English usage would be I have a DER encoded certificate not I have a DER certificate.
.PEM = The PEM extension is used for different types of X.509v3 files which contain ASCII(Base64) armored data prefixed with a -----BEGIN ... line.
Extensions
.CRT = The CRT extension is used for certificates. The certificates may be encoded as binary DER or as ASCII PEM. The CER and CRT extensions are nearly synonymous. Most common among *nix systems.
.CER = Alternate form of .crt(Microsoft Convention). You can use MS to convert .crt to .cer(both DER encoded .cer or PEM encoded .cer).
.KEY = The KEY extension is used both for public and private PKCS#8 keys. The keys may be encoded as binary DER or as ASCII PEM.
# generate private key without password protection
~$ openssl genrsa -out private.key 2048
# generate private key with password protection
~$ openssl genrsa -des3 -out private.key 2048
# check if a private key is valid
~$ openssl rsa -check -in private.key
# check TLS/SSL of website
~$ openssl s_client -connect sonar.wdf.sap.corp:443
# pipes the output from the -showcerts to the x509 ssl command to strip everything extraneous off
~$ openssl s_client -showcerts -connect sonar.wdf.sap.corp:443 </dev/null 2>/dev/null|openssl x509 -outform PEM >mycertfile.pem
# to use the certificate with wget
~$ wget https:/sonar.wdf.sap.corp:443/somepage --ca-certificate=mycertfile.pem
# view PEM encoded certificate
~$ openssl x509 -in cert.pem -text -noout
# view DER encoded certificate
~$ openssl x509 -in cert.der -inform der -text -noout
# transform PEM to DER
~$ openssl x509 -in cert.crt -outform der -out cert.der
# transform DER to PEM
~$ openssl x509 -in cert.crt -inform der -outform pem -out cert.pemSSL/TLS use public and private key system for data encryption and data Integrity. Public keys can be made available to anyone, hence the term public.
Because of this there is a question of trust, specifically: How do you know that a particular public key belongs to the person/entity that it claims. For example, you receive a key claiming to belong to your bank. How do you know that it does belong to your bank? The answer is to use a digital certificate.
Generally a certificate is valid for use on a single fully qualified domain name (FQDN). That is a certificate purchased for use on www.mydomain.com cannot be used on mail.mydomain.com or www.otherdomain.com.
However if you need to secure multiple subdomains as well as the main domain name then you can purchase a Wildcard certificate. For example a wildcard certificate for *.mydomain.com can be used on:
- mail.mydomain.com
- www.mydomain.com
- ftp.mydomain.com
- etc
To cover several different domain names in a single certificate you must purchase a certificate with SAN (Subject Alternative Name).
These generally allow you to secure 4 additional domain names in addition to the main domain name. For example you could use the same certificate on:
TLS uses a combination of symmetric and asymmetric cryptography, as this provides a good compromise between performance and security when transmitting data securely.
TLS uses asymmetric cryptography for securely generating and exchanging a session key. The session key is then used for encrypting the data transmitted by one party, and for decrypting the data received at the other end. Once the session is over, the session key is discarded.
During the course of a TLS handshake, the client and server together will do the following:
- Specify which version of TLS (TLS 1.0, 1.2, 1.3, etc.) they will use
- Authenticate the identity of the server via the server’s public key and the SSL certificate authority’s digital signature
- Generate session keys in order to use symmetric encryption after the handshake is complete
Some networks and internal web resources require users to authenticate themselves using a digital certificate. E.g. EAP-TLS(802.1x) authentication to allow access to LANs and mutual TLS/SSL authentication to allow access to internal resources.