OpenSSL create Client Certificate & Server Certificate with Example


OpenSSL

In this article we will use OpenSSL create client certificate along with server certificate which we will use for encrypted communication for our Apache webserver using HTTPS. These client and server certificates will be signed using CA key and CA certificate bundle which we have created in our previous article.

The list of steps to be followed to generate server client certificate using OpenSSL and perform further verification using Apache HTTPS:

  • Create server certificate
    • Generate server key
    • Generate Certificate Signing Request (CSR) with server key
    • Generate and Sign the server certificate using CA key and certificate
  • Create client certificate
    • Generate client key
    • Generate Certificate Signing request (CSR) with client key
    • Generate and Sign the client certificate using CA key and certificate
  • Configure Apache with SSL
  • Verify openssl server client certificates

 

Lab Environment

I have 3 Virtual Machines in my environment which are installed with CentOS 8 running on Oracle VirtualBox. It is important that you use proper hostname or IP Address in the Common Name section while generate Certificate Signing Request or else the SSL encryption between server and client with fail.

Below are the details of my servers on which I will create client certificate along with other certificates for complete validation.

  Node1 Node2 Node3
Hostname centos8-1 centos8-2 centos8-3
FQDN centos8-1.example.com centos8-2.example.com centos8-3.example.com
IP Address 10.10.10.12 10.10.10.16 10.10.10.17
Purpose Create CA and server client certificates Client using which we will connect to Apache server Server where Apache service will be running

 

Install OpenSSL

On RHEL/CentOS 7/8 you can use yum or dnf respectively while on Ubuntu use apt-get to install openssl rpm

NOTE:
On RHEL system you must have an active subscription to RHN or you can configure a local offline repository using which "yum" package manager can install the provided rpm and it's dependencies.
[root@centos8-1 ~]# yum -y install openssl

 

OpenSSL create client certificate

Let us first create client certificate using openssl.

 

Create client private key

To create client certificate we will first create client private key using openssl command. In this example we are creating client key client.key.pem with 4096 bit size.

[root@centos8-1 certs]# openssl genrsa -out client.key.pem 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
...........................................................................
.................++++
...............................................++++
e is 65537 (0x010001)

 

Create Certificate Signing Request (CSR) using client Key

Next we will use our client key to generate certificate signing request (CSR) client.csr using openssl command.

[root@centos8-1 certs]# openssl req -new -key client.key.pem -out client.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:IN
State or Province Name (full name) []:Karnataka
Locality Name (eg, city) [Default City]:bengaluru
Organization Name (eg, company) [Default Company Ltd]:GoLinuxCloud
Organizational Unit Name (eg, section) []:R&D
Common Name (eg, your name or your server's hostname) []:centos8-2
Email Address []:admin@golinuxcloud.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

 

Configure openssl x509 extensions for client certificate

It is important to define openssl x509 extensions to be used to create client certificate. You can read more about these extensions at the man page of openssl x509.

[root@centos8-1 certs]# cat client_cert_ext.cnf
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

Here,

basicConstraints      : An end user certificate must either set CA to FALSE or exclude the extension entirely
nsCertType            : This is Netscape Certificate Type which consists of a list of flags to be included. 
                        Acceptable values for nsCertType are: client, server, email, objsign, reserved, sslCA, emailCA, objCA
nsComment             : Netscape Comment (nsComment) is a string extension containing a comment which will be displayed 
                        when the certificate is viewed in some browsers.
subjectKeyIdentifier  : This is really a string extension and can take two possible values. Either the word hash which will 
                        automatically follow the guidelines in RFC3280 or a hex string giving the extension value to include.
authorityKeyIdentifier: The authority key identifier extension permits two options. keyid and issuer: both can take the optional value "always".
keyUsage              : Key usage is a multi valued extension consisting of a list of names of the permitted key usages.
extendedKeyUsage      : This extensions consists of a list of usages indicating purposes for which the certificate public key can be used for,

 

Create client certificate

[root@centos8-1 certs]# openssl x509 -req -in client.csr -CA /root/tls/intermediate/certs/ca-chain-bundle.cert.pem -CAkey /root/tls/intermediate/private/intermediate.cakey.pem -out client.cert.pem -CAcreateserial -days 365 -sha256 -extfile client_cert_ext.cnf
Signature ok
subject=C = IN, ST = Karnataka, L = bengaluru, O = GoLinuxCloud, OU = R&D, CN = centos8-2, emailAddress = admin@golinuxcloud.com
Getting CA Private Key

 

Openssl verify client certificate content

In this section we have created below files:

  • client.key.pem   ⇒ Client private key
  • client.csr           ⇒ Client CSR
  • client.cert.pem  ⇒ Client Certificate

You can use below commands to verify the content of these certificates:

# openssl rsa -noout -text -in client.key.pem
# openssl req -noout -text -in client.csr
# openssl x509 -noout -text -in client.cert.pem

 

OpenSSL create server certificate

Next we will create server certificate using openssl.

 

Create server private key

To create server certificate we will first create server private key using openssl command. In this example we are creating server key server.key.pem with 4096 bit size.

[root@centos8-1 certs]# openssl genrsa -out server.key.pem 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
....++++
.......................++++
e is 65537 (0x010001)

 

Create Certificate Signing Request (CSR) using Server Key

Next we will use our server key server.key.pem to generate certificate signing request (CSR) server.csr using openssl command.

IMPORTANT NOTE:
It is very important that you provide the hostname or IP address value of your server node with Common Name or else the server client TCP handshake will fail if the hostname does not matches the CN of the server certificate. Our server hostname is centos8-3 as you can check under Lab Environment.
[root@centos8-1 certs]# openssl req -new -key server.key.pem -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:IN
State or Province Name (full name) []:Karnataka
Locality Name (eg, city) [Default City]:Bengaluru
Organization Name (eg, company) [Default Company Ltd]:GoLinuxCloud
Organizational Unit Name (eg, section) []:R&D
Common Name (eg, your name or your server's hostname) []:centos8-3
Email Address []:admin@golinuxcloud.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

 

Configure openssl x509 extensions for server certificate

It is again important to define openssl x509 extensions to be used to create server certificate. These extensions value will differentiate between your server and client certificate. You can read more about these extensions at the man page of openssl x509.

[root@centos8-1 certs]# cat server_cert_ext.cnf
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

You can compare these values with what we defined under our client certificate extensions

 

Create server certificate

  • We will use similar command as used to create client certificate, openssl x509 to create server certificate and sign it using our server.csr which we created above.
  • We will use CA certificate (certificate bundle) and CA key from our previous article to issue and sign the certificate
  • The server certificate will be valid for 365 days and encrypted with sha256 algorithm
  • Define the absolute path and filename of the configuration file which contains openssl x509 extensions for your server certificate using -extfile. If you are using default openssl.cnf then you can also create an extensions section in your openssl.cnf and use -extensions with the key value from openssl.cnf to define your extensions.
  • The subject in the output contains our CSR details which we provided with server.csr
  • This command will create server certificate server.cert.pem
[root@centos8-1 certs]# openssl x509 -req -in server.csr -CA /root/tls/intermediate/certs/ca-chain-bundle.cert.pem -CAkey /root/tls/intermediate/private/intermediate.cakey.pem -out server.cert.pem -CAcreateserial -days 365 -sha256 -extfile server_cert_ext.cnf
Signature ok
subject=C = IN, ST = Karnataka, L = Bengaluru, O = GoLinuxCloud, OU = R&D, CN = centos8-3, emailAddress = admin@golinuxcloud.com
Getting CA Private Key

 

Openssl verify server certificate content

In this section we have created below files:

  • server.key.pem   ⇒ Server private key
  • server.csr           ⇒ Server CSR
  • server.cert.pem  ⇒ Server Certificate

You can use below commands to verify the content of these certificates:

# openssl rsa -noout -text -in server.key.pem
# openssl req -noout -text -in server.csr
# openssl x509 -noout -text -in server.cert.pem

 

Configure Apache with SSL (HTTPS)

I will not go much into the detail steps to configure Apache with HTTPS as that in not our primary agenda of this article. I will configure a basic webserver to use Port 8443 on centos8-3

 

Install Apache Package

To setup HTTPS apache server we need to install httpd and mod_ssl. In RHEL/CentoS 8 the default package manager is DNF instead of traditional YUM

[root@centos8-3 ~]# dnf -y install httpd mod_ssl

 

Arrange all the server certificates for client authentication

I have created a new directory certs under /etc/httpd/conf.d where I will store all the server certificates and the same path is provided in our httpd.cond

[root@centos8-3 certs]# mkdir /etc/httpd/conf.d/certs

Copy server certificates to the server node i.e. centos8-3. We are using scp to copy files from one server to another but you can choose any other tool to transfer the certificates securely over the network.

[root@centos8-1 certs]# scp server.key.pem server.cert.pem /root/tls/intermediate/certs/ca-chain-bundle.cert.pem  centos8-3:/etc/httpd/conf.d/certs/
root@centos8-3's password:
server.key.pem                                                                                    100% 3243     3.8MB/s   00:00
server.cert.pem                                                                                   100% 2484     2.7MB/s   00:00
ca-chain-bundle.cert.pem                                                                          100% 4240     5.9MB/s   00:00

Since we plan to use a custom port 8443 to verify our server client authentication and TCP handshake, we will change the Listen value from 80 to 8443 in httpd.conf

[root@centos8-3 ~]# vim /etc/httpd/conf/httpd.conf
Listen 8443

 

Configure Apache Virtual Hosting

I have added below virtual hosting content at the end of "/etc/httpd/conf/httpd.conf". You can read more about Apache Virtual Hosting in another article.

<VirtualHost *:8443>
   SSLEngine On
   SSLCertificateFile /etc/httpd/conf.d/certs/server.cert.pem
   SSLCertificateChainFile /etc/httpd/conf.d/certs/ca-chain-bundle.cert.pem
   SSLCertificateKeyFile /etc/httpd/conf.d/certs/server.key.pem
   ServerAdmin root@centos8-3.example.com
   DocumentRoot /var/www/html
   ServerName centos8-3.example.com
   ErrorLog logs/centos8-3.example.com-error_log
   CustomLog logs/centos8-3.example.com-access_log common
</VirtualHost>

For more list of supported options follow man page of mod_ssl.

Here,

SSLEngine               : This section is used to enable SSL/TLS for a that virtual host.
SSLCertificateFile      : This directive points to a file with certificate data in PEM format
SSLCertificateChainFile : This directive sets the optional all-in-one file where you can assemble 
                          the certificates of Certification Authorities (CA) which form the certificate
                          chain of the server certificate
SSLCertificateKeyFile   : This directive points to the PEM-encoded private key file for the server

To activate the changes we must restart the httpd services and then you can use netstat or any other tool to check the list of listening ports in Linux.

[root@centos8-3 ~]# systemctl restart httpd

As you see port 8443 is in LISTEN state so our changes are activated.

[root@centos8-3 ~]# netstat -ntlp | grep 8443
tcp6       0      0 :::8443                 :::*                    LISTEN      5602/httpd

 

Verify TCP Handshake using Client Server Certificates

First let us try to connect our Apache webserver without providing any client certificates using curl command and verbose output.

[root@centos8-1 certs]# curl  https://centos8-3:8443 -v                                                                             
* Rebuilt URL to: https://centos8-3:8443/
*   Trying 10.10.10.17...
* TCP_NODELAY set
* Connected to centos8-3 (10.10.10.17) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

As expected we are getting Failed TCP handshake error and our client was unable to connect to the web server.

Next let us try to connect to our web server using the client certificates. Use --key to define the client key file, --cert to define the client certificate and --cacert to define the CA certificate we used to sign the certificates followed by the web server address.

[root@centos8-1 certs]# curl --key client.key.pem  --cert client.cert.pem --cacert /root/tls/intermediate/certs/ca-chain-bundle.cert.pem  https://centos8-3:8443 -v
* Rebuilt URL to: https://centos8-3:8443/
*   Trying 10.10.10.17...
* TCP_NODELAY set
* Connected to centos8-3 (10.10.10.17) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /root/tls/intermediate/certs/ca-chain-bundle.cert.pem
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=IN; ST=Karnataka; L=Bengaluru; O=GoLinuxCloud; OU=R&D; CN=centos8-3; emailAddress=admin@golinuxcloud.com
*  start date: Apr 11 07:35:43 2020 GMT
*  expire date: Apr 11 07:35:43 2021 GMT
*  common name: centos8-3 (matched)
*  issuer: C=IN; ST=Some-State; O=GoLinuxCloud; CN=centos8-1 Intermediate CA; emailAddress=admin@golinuxcloud.com
*  SSL certificate verify ok.
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> GET / HTTP/1.1
> Host: centos8-3:8443
> User-Agent: curl/7.61.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
< HTTP/1.1 200 OK
< Date: Sat, 11 Apr 2020 07:37:28 GMT
< Server: Apache/2.4.37 (centos) OpenSSL/1.1.1c
< Last-Modified: Fri, 31 Jan 2020 17:29:35 GMT
< ETag: "29-59d72ead47e18"
< Accept-Ranges: bytes
< Content-Length: 41
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host centos8-3 left intact
Welcome at the Ansible managed web server

So our server and client certificate authentication is working as expected.

But what if you try to access the web server using IP address instead of hostname? Let us examine this scenario:

[root@centos8-1 tls]# curl --key private/client.key.pem  --cert certs/client.cert.pem --cacert intermediate/certs/ca-chain-bundle.cert.pem  https://10.10.10.17:8443 -v
* Rebuilt URL to: https://10.10.10.17:8443/
*   Trying 10.10.10.17...
* TCP_NODELAY set
* Connected to 10.10.10.17 (10.10.10.17) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: intermediate/certs/ca-chain-bundle.cert.pem
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=IN; ST=Some-State; L=BANGALORE; O=GoLinuxCloud; CN=centos8-3
*  start date: Apr  9 01:49:53 2020 GMT
*  expire date: Apr  9 01:49:53 2021 GMT
* SSL: certificate subject name 'centos8-3' does not match target host name '10.10.10.17'
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, [no content] (0):
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (51) SSL: certificate subject name 'centos8-3' does not match target host name '10.10.10.17'

This is the reason I had stressed on the point to make sure you give proper Common Name for server when you create server certificate. The provided Common Name will be used to match the server request and further authentication.

Now it also possible that you would like to reach your web server using other CNAME or IP Addresses so in such case you will end up creating multiple server certificates or to avoid this we can create SAN certificates.

We will learn more about SAN certificates in the next article

Lastly I hope the steps from the article to create client certificate and create server certificate using openssl to establish an encrypted communication between server and client on Linux was helpful. So, let me know your suggestions and feedback using the comment section.

 

Deepak Prasad

Deepak Prasad

Deepak Prasad is the founder of GoLinuxCloud, bringing over a decade of expertise in Linux, Python, Go, Laravel, DevOps, Kubernetes, Git, Shell scripting, OpenShift, Networking, and Security. His extensive experience spans development, DevOps, networking, and security, ensuring robust and efficient solutions for diverse projects.

Certifications and Credentials:

  • Certified Kubernetes Application Developer (CKAD)
  • Go Developer Certification
  • Linux Foundation Certified System Administrator (LFCS)
  • Certified Ethical Hacker (CEH)
  • Python Institute PCAP (Certified Associate in Python Programming)
You can connect with him on his LinkedIn profile and join his Facebook and LinkedIn page.

Can't find what you're searching for? Let us assist you.

Enter your query below, and we'll provide instant results tailored to your needs.

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

Buy GoLinuxCloud a Coffee

For any other feedbacks or questions you can send mail to admin@golinuxcloud.com

Thank You for your support!!

14 thoughts on “OpenSSL create Client Certificate & Server Certificate with Example”

  1. Hello, I added CA and client (pkcs12) certificate in chrome, but when I access my website, I get “This site can’t provide a secure connection10.22.10.10 didn’t accept your login certificate, or one may not have been provided”. How to solve this error? Thanks

    Reply
  2. Thanks very much for the informative article.
    I have a question that was to some extent already asked by Elanor, but I couldn’t understand the answer so wish to ask again.
    In the example given client on centso8-1 could connect to the apache server using the client key and certificate created with a CN of centos8-2. Does that mean we can use that client key and certificate files on ANY client machines and be able to connect to the apache server?
    Thanks

    Reply
  3. Hi to everybody,

    I am trying to implement a IEC62351 communication between client ad server. What I know is that I need:

    for the client
    – private_key.pem
    – cert.pem
    – ca.pem -> this has to be imported even in the server side

    for the server
    – private_key.pem
    – cert.pem
    – ca.pem -> this has to be imported even in the client side

    that said, I still haven’t been able to generate the correct certificates. Can someone kindly help me?

    Thank you in advance.

    Reply
  4. Hi

    Very good tutorial! Thanks!
    How can i now add these Certificates to my local (client) side PC so i will not get asked “Warning self signed Cert” in the browser/apps ? And wich one do i add ? as I understand, i only need to add the cert-bundle from the root ca. This way it will trust the Server Cert (intermidiate Ca). Is this correct ? However i do not fully understand why there is a client certificate. On Webpages on the internet there is no client cert. Also how do i add it to my normal cert vault ?

    Im useing Arch Linux.

    Thanks

    Reply
    • 1. For intranet we can import our CA bundle to the browser and then add the cert to your application in which case the connection will not be marked as unsecure
      2. Browser performs TLS only where the server cert is verified against the CA certificate
      3. Client certificate is used for MTLS connection in which case both server and client certs are validated. This is used in many interfaces such as HTTPS, SOAP, etc

      Reply
  5. Sorry, update
    —————————————————–
    Hi~
    Thank you very much, these articles help a lot.
    But I have a question about the client certification.
    In the section .
    “It is very important that you provide the hostname or IP address value of your client node with Common Name or else the server client TCP handshake will fail if the hostname does not matches the CN of the client certificate. Our client hostname is centos8-2 as you can check under Lab Environment.”
    I thought this means that the server will only accept the TLS connection from the client hosts or IPs we defined in the Common Name or subjectAltName list when generating client.csr.
    Did I get it wrong?
    In this section the common name of the client certification is “centos8-2”.
    But in the section , the host “centos8-1” was used to connect to the web server using the client certificates successfully.
    Is this means the common name in client certification not really have to match the client host name or IP we actually used to do the TCP handshake?
    Another question is: can we do the TCP handshake with server (not using browser) without using the client certification and how does it work?
    Copy the intermediate certification to the client?
    These really confused me.
    Really appreciate!

    Reply
    • The first one “section” is the section [OpenSSL create client certificate].
      The second one is the section [Verify TCP Handshake using Client Server Certificates]

      Reply
      • Hi Eleanor, thank you for highlighting this. We do need to make sure the client certificate also has proper hostname but here in this article since I have shown communication from client to server then it wouldn’t matter although if the communication is reverse then that would matter. But since I don’t cover the other scenario in this article, I have removed the NOTE section and also made some minor corrections.

        You always have to target your server whom you plan to connect and use it’s DNS/IP value while generating the server certificate. If it is a two way communication then also use proper hostnames for client certificate.

        Reply

Leave a Comment