A guide to creating self-signed certificates

A guide to creating self-signed certificates

During the SD-WAN implementation in my lab, I had to create the Root CA, generate CSRs, and generate self-signed certificates. It was a very positive experience. I will discuss the self-signed certificate today. I will share the steps so we can use them for general-purpose on any network devices.

In networking, certificates serve a variety of purposes. We can use them for user authentication, server authentication or between network devices like routers/firewalls for IPSec.


Several network devices, including routers, firewalls, and access points, come with self-signed certificates that automatically regenerate whenever they are rebooted. If any client attempts to connect to the device, the web browser of your user will give an untrusted certificate warning (since the self-signed certificate is not owned by the CA). We have two options for fixing this problem:


  • An SSL certificate from a trusted CA should be purchased and installed on the device.
  • Create a self-signed SSL certificate on the device and export it to the user's computer.

In the first option, you purchase an SSL certificate from a provider such as Verisign, Entrust, Godaddy, etc. and install it on the device. There are a lot of pre-installed root CA certificates from these providers, so when you get an SSL certificate from them, your browser will display it as trusted. The user doesn't have to do anything on their computer.

We can use the second option if you don't want to buy an SSL certificate. A self-signed SSL certificate will be generated on the device. There is no need to export and import this certificate on each of your remote users' computers since it is permanent, so it won't disappear when you reboot the device.

In this lesson, we will generate the SSL certificate, self-sign it, and then export and import it in the browser.

To accomplish this, I will use the Open SSL tool, and I use Mac, so Open SSL will be installed by default.

There are a number of requirements for certificates. PKI (Public Key Infrastructure) requires keys...a public and a private key. These two keys are automatically generated when we generate an RSA key. To encrypt or sign messages, the public key can be shared with anyone. To generate the keys, follow these steps:

STEP 1 :Create a private key and public certificate using the following command:

 I will first generate a root CA key called ROOTCA.Key.


  PKUMARI4-M-92EL:~ pkumari4$ openssl

 

OpenSSL> genrsa -out ROOTCA.Key 4096

Generating RSA private key, 4096 bit long modulus

............................................................................................++

....................................................................................................................................++

e is 65537 (0x10001)        

The key size is 4096 and I am trying to output it to the file CA.Key.

STEP 2. Create a ROOT certificate and sign it with the ROOTCA.key.

A CA normally uses the .csr file to issue the certificate, but in this case, we can create our own certificate using the .csr file. The command will prompt you to enter your country, company name, etc.


 OpenSSL>  req -new -x509 -days 1826 -key ROOTCA.Key -out ROOTCA.crt          

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) []:IN

State or Province Name (full name) []:KA

Locality Name (eg, city) []:BN

Organization Name (eg, company) []:vTAC-India - 22201

Organizational Unit Name (eg, section) []:

Common Name (eg, fully qualified host name) []:example.com

Email Address []:test@example.com

OpenSSL>         

 The certificate type I am using is -x590 and the validity period is 5 years (1826 days). It will ask you a few questions when you create the certificate, such as the company name, the FQDN, and the email address.

Example.com is now the FQDN for the certificate. A remote user must use the FQDN to access the device from a web browser. A certificate error will still occur if you use the IP address!

STEP 3. Our ROOT Key is ROOTCA.Key, and our ROOT CA is ROOTCA.CRT.

Knowing that we need a chain of certificates, the intermediate certificate will be generated after the ROOT certificate's private key.

 OpenSSL> genrsa -out is.key 4096        


Generating RSA private key, 4096 bit long modulu

................................................................................++

.......................................................................................++

e is 65537 (0x10001)s        

I will now create the intermediate certificate, but it will not be self-signed; it will be signed by the root authority. To do this, we need to generate a certificate signing request. You need to provide the same information, but make sure the FQDN for the root and intermediate certificates are different

 OpenSSL> req -new -key is.key -out is.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) []:IN

State or Province Name (full name) []:KA

Locality Name (eg, city) []:BN

Organization Name (eg, company) []:vTAC-India - 22201 

Organizational Unit Name (eg, section) []:

Common Name (eg, fully qualified host name) []:www.example.com

Email Address []:test@example.com

 

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:admin@123

         

The .csr file for the intermediate certificate has been signed by the ROOT CA. The request has been created and will now be processed. My certificate type is x509, and I'm asking for two years, so 730 days. Input is is.csr, which is my CSR request, and again I'm going to need the root certificate and its key, as my intermediate certificate will be signed by root, so I'm giving the name of my intermediate certificate.


OpenSSL> x509 -req -days 730 -in is.csr -CA ROOTCA.crt -CAkey ROOTCA.Key -set_serial 02 -out is.crt

Signature ok

subject=/C=IN/ST=KA/L=BN/O=vTAC-India - 22201/CN=www.example.com/emailAddress=test@example.com

Getting CA Private Ke

 

         

This will be keep in PKCS12 format with is.key as my intermediate key

OpenSSL>  pkcs12 -export -out is.p12 -inkey is.key -in is.crt -chain -CAfile ROOTCA.crt 

Enter Export Password:

Verifying - Enter Export Password:

OpenSSL> 

 

         

An intermediate certificate provides an additional level of security since the CA does not need to issue certificates directly from the root certificate. An Intermediate CA (Certificate Authority) provides trust chaining to a trusted root in an SSL connection

The above-created Root Certificate can be retrieved


No alt text provided for this image
Atish Prusty

Technical Leader at Cisco

1y

Good one Priyanka

Again an in-depth blog. Initially when you mentioned the options to fix this , there are actually three. If an enterprise has its own internal PKI a server certificate can be also obtained from that.

Saswata Chakraborty

Network Development Engineer II @ Amazon | Ex-Salesforce | IIMC - EPGM’27

1y

Nice one Priyanka

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics