Related
May 13, 2019 There are two steps involved in generating a certificate signing request (CSR). First, you have to generate a private key, and then generate CSR using that private key. Step 1: Generate a private key. Enter the following command in the Terminal with sudo to generate a private key using RSA algorithm with a key length of 2048 bits. I have purchased the SSL certificate from GoDaddy and i need to install this SSL certificate on siteground server because my site is hosted on siteground. But i am facing the issue with private key because when i try to set up the SSL certificate on Siteground it ask for private key and in am not.
Introduction
TLS, or transport layer security, and its predecessor SSL, secure sockets layer, are secure protocols created in order to place normal traffic in a protected, encrypted wrapper.
These protocols allow traffic to be sent safely between remote parties without the possibility of the traffic being intercepted and read by someone in the middle. They are also instrumental in validating the identity of domains and servers throughout the internet by establishing a server as trusted and genuine by a certificate authority.
In this guide, we’ll cover how to create a self-signed SSL certificate for Apache on an Ubuntu 14.04 server, which will allow you to encrypt traffic to your server. While this does not provide the benefit of third party validation of your server’s identity, it fulfills the requirements of those simply wanting to transfer information securely.
Note: You may want to consider using Let’s Encrypt instead of a self-signed certificate. Let’s Encrypt is a new certificate authority that issues free SSL/TLS certificates that are trusted in most web browsers. Check out the tutorial to get started: How To Secure Apache with Let’s Encrypt on Ubuntu 14.04
Prerequisites
Before you begin, you should have some configuration already taken care of.
We will be operating as a non-root user with sudo privileges in this guide. You can set one up by following steps 1-4 in our Ubuntu 14.04 initial server setup guide.
You are also going to need to have Apache installed. If you don’t already have that up and running, you can quickly fix that by typing:
Step One — Activate the SSL Module
SSL support actually comes standard in the Ubuntu 14.04 Apache package. We simply need to enable it to take advantage of SSL on our system.
Enable the module by typing:
After you have enabled SSL, you’ll have to restart the web server for the change to be recognized:
With that, our web server is now able to handle SSL if we configure it to do so.
Step Two — Create a Self-Signed SSL Certificate
Let’s start off by creating a subdirectory within Apache’s configuration hierarchy to place the certificate files that we will be making:
Now that we have a location to place our key and certificate, we can create them both in one step by typing:
Let’s go over exactly what this means.
- openssl: This is the basic command line tool provided by OpenSSL to create and manage certificates, keys, signing requests, etc.
- req: This specifies a subcommand for X.509 certificate signing request (CSR) management. X.509 is a public key infrastructure standard that SSL adheres to for its key and certificate managment. Since we are wanting to create a new X.509 certificate, this is what we want.
- -x509: This option specifies that we want to make a self-signed certificate file instead of generating a certificate request.
- -nodes: This option tells OpenSSL that we do not wish to secure our key file with a passphrase. Having a password protected key file would get in the way of Apache starting automatically as we would have to enter the password every time the service restarts.
- -days 365: This specifies that the certificate we are creating will be valid for one year.
- -newkey rsa:2048: This option will create the certificate request and a new private key at the same time. This is necessary since we didn’t create a private key in advance. The
rsa:2048
tells OpenSSL to generate an RSA key that is 2048 bits long. - -keyout: This parameter names the output file for the private key file that is being created.
- -out: This option names the output file for the certificate that we are generating.
When you hit “ENTER”, you will be asked a number of questions.
Generate Private Key For Ssl Certificate Ubuntu Pdf
The most important item that is requested is the line that reads “Common Name (e.g. server FQDN or YOUR name)”. You should enter the domain name you want to associate with the certificate, or the server’s public IP address if you do not have a domain name.
The questions portion looks something like this:
The key and certificate will be created and placed in your /etc/apache2/ssl
directory.
Step Three — Configure Apache to Use SSL
Now that we have our certificate and key available, we can configure Apache to use these files in a virtual host file. You can learn more about how to set up Apache virtual hosts here.
Instead of basing our configuration file off of the 000-default.conf
file in the sites-available
subdirectory, we’re going to base this configuration on the default-ssl.conf
file that contains some default SSL configuration.
Open the file with root privileges now:
With the comments removed, the file looks something like this:
This may look a bit complicated, but luckily, we don’t need to worry about most of the options here.
We want to set the normal things we’d configure for a virtual host (ServerAdmin, ServerName, ServerAlias, DocumentRoot, etc.) as well as change the location where Apache looks for the SSL certificate and key.
In the end, it will look something like this. The entries in red were modified from the original file:
Save and exit the file when you are finished.
Step Four — Activate the SSL Virtual Host
Now that we have configured our SSL-enabled virtual host, we need to enable it.
We can do this by typing:
We then need to restart Apache to load our new virtual host file:
This should enable your new virtual host, which will serve encrypted content using the SSL certificate you created.
Step Five — Test your Setup
Now that you have everything prepared, you can test your configuration by visiting your server’s domain name or public IP address after specifying the https://
protocol, like this:
You will get a warning that your browser cannot verify the identity of your server because it has not been signed by one of the certificate authorities that it trusts.
This is expected since we have self-signed our certificate. While our certificate will not validate our server for our users because it has had no interaction with a trusted certificate authority, it will still be able to encrypt communication.
Since this is expected, you can hit the “Proceed anyway” button or whatever similar option you have in your browser.
You will now be taken to content in the DocumentRoot
that you configured for your SSL virtual host. This time your traffic is encrypted. You can check this by clicking on the lock icon in the menu bar:
You can see in the middle green section that the connection is encrypted.
Conclusion
You should now have SSL enabled on your website. This will help to secure communication between visitors and your site, but it will warn each user that the browser cannot verify the validity of the certificate.
If you are planning on launching a public site and need SSL, you will be better off purchasing an SSL certificate from a trusted certificate authority.
If you want to learn more about how to configure Apache, click here. Check out this link for more ideas on how to secure your Linux server.
One of the most common forms of cryptography today is public-key cryptography. Public-key cryptography utilizes a public key and a private key. The system works by encrypting information using the public key. The information can then only be decrypted using the private key.
A common use for public-key cryptography is encrypting application traffic using a Secure Socket Layer (SSL) or Transport Layer Security (TLS) connection. One example: configuring Apache to provide HTTPS, the HTTP protocol over SSL. This allows a way to encrypt traffic using a protocol that does not itself provide encryption.
A Certificate is a method used to distribute a public key and other information about a server and the organization who is responsible for it. Certificates can be digitally signed by a Certification Authority, or CA. A CA is a trusted third party that has confirmed that the information contained in the certificate is accurate.
To set up a secure server using public-key cryptography, in most cases, you send your certificate request (including your public key), proof of your company's identity, and payment to a CA. The CA verifies the certificate request and your identity, and then sends back a certificate for your secure server. Alternatively, you can create your own self-signed certificate.
Note that self-signed certificates should not be used in most production environments.
Continuing the HTTPS example, a CA-signed certificate provides two important capabilities that a self-signed certificate does not:
Browsers (usually) automatically recognize the certificate and allow a secure connection to be made without prompting the user.
When a CA issues a signed certificate, it is guaranteeing the identity of the organization that is providing the web pages to the browser.
Most Web browsers, and computers, that support SSL have a list of CAs whose certificates they automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser asks the user to either accept or decline the connection. Also, other applications may generate an error message when using a self-signed certificate.
The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:
Create a private and public encryption key pair.
Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it.
Send the certificate request, along with documents proving your identity, to a CA. We cannot tell you which certificate authority to choose. Your decision may be based on your past experiences, or on the experiences of your friends or colleagues, or purely on monetary factors.
Once you have decided upon a CA, you need to follow the instructions they provide on how to obtain a certificate from them.
When the CA is satisfied that you are indeed who you claim to be, they send you a digital certificate.
Install this certificate on your secure server, and configure the appropriate applications to use the certificate.
Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key.
If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc., a key without a passphrase is often appropriate. Not having a passphrase allows the services to start without manual intervention, usually the preferred way to start a daemon.
This section will cover generating a key with a passphrase, and one without. The non-passphrase key will then be used to generate a certificate that can be used with various service daemons.
Running your secure service without a passphrase is convenient because you will not need to enter the passphrase every time you start your secure service. But it is insecure and a compromise of the key means a compromise of the server as well.
To generate the keys for the Certificate Signing Request (CSR) run the following command from a terminal prompt:
You can now enter your passphrase. For best security, it should at least contain eight characters. The minimum length when specifying -des3 is four characters. It should include numbers and/or punctuation and not be a word in a dictionary. Also remember that your passphrase is case-sensitive.
Re-type the passphrase to verify. Once you have re-typed it correctly, the server key is generated and stored in the server.key file.
Now create the insecure key, the one without a passphrase, and shuffle the key names:
The insecure key is now named server.key, and you can use this file to generate the CSR without passphrase.
To create the CSR, run the following command at a terminal prompt:
It will prompt you enter the passphrase. If you enter the correct passphrase, it will prompt you to enter Company Name, Site Name, Email Id, etc. Once you enter all these details, your CSR will be created and it will be stored in the server.csr file.
You can now submit this CSR file to a CA for processing. The CA will use this CSR file and issue the certificate. On the other hand, you can create self-signed certificate using this CSR.
To create the self-signed certificate, run the following command at a terminal prompt:
Generate Private Key For Ssl Certificate Ubuntu Free
The above command will prompt you to enter the passphrase. Once you enter the correct passphrase, your certificate will be created and it will be stored in the server.crt file.
If your secure server is to be used in a production environment, you probably need a CA-signed certificate. It is not recommended to use self-signed certificate.
You can install the key file server.key and certificate file server.crt, or the certificate file issued by your CA, by running following commands at a terminal prompt:
Now simply configure any applications, with the ability to use public-key cryptography, to use the certificate and key files. For example, Apache can provide HTTPS, Dovecot can provide IMAPS and POP3S, etc.
If the services on your network require more than a few self-signed certificates it may be worth the additional effort to setup your own internal Certification Authority (CA). Using certificates signed by your own CA, allows the various services using the certificates to easily trust other services using certificates issued from the same CA.
Generate Private Key For Ssl Certificate Ubuntu Free
First, create the directories to hold the CA certificate and related files:
The CA needs a few additional files to operate, one to keep track of the last serial number used by the CA, each certificate must have a unique serial number, and another file to record which certificates have been issued:
The third file is a CA configuration file. Though not strictly necessary, it is very convenient when issuing multiple certificates. Edit /etc/ssl/openssl.cnf, and in the [ CA_default ] change:
Next, create the self-signed root certificate:
You will then be asked to enter the details about the certificate.
Now install the root certificate and key:
You are now ready to start signing certificates. The first item needed is a Certificate Signing Request (CSR), see Generating a Certificate Signing Request (CSR) for details. Once you have a CSR, enter the following to generate a certificate signed by the CA:
After entering the password for the CA key, you will be prompted to sign the certificate, and again to commit the new certificate. You should then see a somewhat large amount of output related to the certificate creation.
There should now be a new file, /etc/ssl/newcerts/01.pem, containing the same output. Copy and paste everything beginning with the line: -----BEGIN CERTIFICATE----- and continuing through the line: ----END CERTIFICATE----- lines to a file named after the hostname of the server where the certificate will be installed. For example mail.example.com.crt, is a nice descriptive name.
Subsequent certificates will be named 02.pem, 03.pem, etc.
Replace mail.example.com.crt with your own descriptive name.
Finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. The default location to install certificates is /etc/ssl/certs. This enables multiple services to use the same certificate without overly complicated file permissions.
For applications that can be configured to use a CA certificate, you should also copy the /etc/ssl/certs/cacert.pem file to the /etc/ssl/certs/ directory on each server.
Generate Private Key For Ssl Certificate Ubuntu Windows 10
For more detailed instructions on using cryptography see the SSL Certificates HOWTO by tldp.org:
The Wikipedia HTTPS page has more information regarding HTTPS.
For more information on OpenSSL see the OpenSSL Home Page.
Also, O'Reilly's Network Security with OpenSSL is a good in-depth reference.