How to Create a Self Signed Certificate

A self-signed certificate is a certificate that is signed by the person creating it rather than a trusted certificate authority. Self-signed certificates can enable the same level of encryption as a $1500 certificate signed by a trusted authority, but there are two major drawbacks: a visitor's connection could be hijacked allowing an attacker view all the data sent (thus defeating the purpose of encrypting the connection) and the certificate cannot be revoked like a trusted certificate can. We're going to explain when a self-signed certificate should and shouldn't be used and then share tutorials on how to generate a self-signed certificate for common platforms like Microsoft IIS, Apache, and Java Keytool.

When to Use a Self-Signed Certificate

Self-signed certificates or certificates issued by a private CAs are not appropriate for use with the general public.

A certificate serves two essential purposes: distributing the public key and verifying the identity of the server so visitors know they aren’t sending their information to the wrong person. It can only properly verify the identity of the server when it is signed by a trusted third party because any attacker can create a self-signed certificate and launch a man-in-the-middle attack. If a user just accepts a self-signed certificate, an attacker could eavesdrop on all the traffic or try to set up an imitation server to phish additional information out of the user. Because of this, you will almost never want to use a self signed certificate on a server that requires anonymous visitors to connect to your site. In these cases, you really need to lay down a few bucks on a trusted certificate (there are plenty of cheap SSL certificates and even free options). However, self-signed certificates can have their place:

An Intranet. When clients only have to go through a local Intranet to get to the server, there is virtually no chance of a man-in-the-middle attack.
A development server. There is no need to spend extra cash buying a trusted certificate when you are just developing or testing an application.
Personal sites with few visitors. If you have a small personal site that transfers non-critical information, there is very little incentive for someone to attack the connections.

Just keep in mind that visitors will see a warning in their browsers (like the one below) when connecting to a server that uses a self-signed certificate until it is permanently stored in their certificate store.

Apache Self signed Certificate Error in Firefox

A Better Option: Private CAs

If you are going to use a self-signed certificate for one of the situations where they are appropriate, it is much better to create your own private CA certificate. This is a more secure option that allows you to avoid warnings like the one displayed above for doing just a little bit more work.

Self Signed Certificates In IIS

Creating a self-signed certificate in IIS 7 is much easier to do than in previous versions of IIS. IIS now provides a simple interface for generating a self-signed certificate. One drawback, is that the common name of the certificate is always the server name instead of the site name. In order to change the common name, you'll need to follow some additional steps.

How to Create a Self-Signed Certificate in IIS 7

Self Signed Certificates for Apache

Creating a self-signed certificate to secure an Apache site requires the use of OpenSSL. This gives you full control over how the certificate is created.

How to Create and Install an Apache Self-Signed Certificate

Self Signed Certificates for Java

Generating a self-signed certificate with Java Keytool is (usually) the simplest of all the platforms, though you don't get quite as much control as using OpenSSL.

How to Create a Self-Signed Certificate using Java Keytool

For more information on creating self-signed certificate, see the following links:

Originally posted on Sat Jun 16, 2007

Comments

perf(2014-12-13)
Here is an online self-signed certificate generator: http://www.selfsignedcertif...
Robert Talada(2016-05-02)
Letting someone else handle the generation of a self-signed certificate for you is such a bad idea on so many levels. They could be building a database of self-signed sites and likely have all of the certificates and keys. Nobody should use this site.
Robert Talada(2019-10-16)
Revisiting this comment three years later, this advice still stands. I am glad to see that my advice has withstood the test of time.
Android23(2020-01-29)
Just being curious here, how did your comment withstand the test of time? Was there any known incidence of a malicious website storing a database of self-signed sites?
Tapan(2014-12-13)
Very helpful. Thanks so much.
Ross(2014-12-13)
I am assuming that once the certificate is accepted that you no longer get the invalid certificate message. If only a few people were accessing the site, they would have the correct certificate, and if someone tried to hijack it they would get another invalid certificate message, right? Is there any other information in the certificate error message that would let a educated user figure out whether the certificate was from the local site? Thanks, Ross
Robert(2014-12-13)
The connection is actually vulnerable to attack if a self signed certificate is used because anyone can create a self signed certificate with the exact same details (except the private key) and then execute a man-in-the-middle attack to intercept all of the traffic between a client and the server without anyone noticing.
Shawn Zernik(2014-12-13)
To set up this trust, the clients must trust the root of the serverÃ¢Â€Â™s certificate. This means, clients have to possess the certificate of the certification authority that issued the server certificate in their Trusted Root Certification Authorities store. You can observe this store via the Certificates snap-in. The process is mandatory if you are using a certificate not issued by a third part vendor. Important To install the server root certificate, do the following on the client. To install the root Certificate on the client 1.Open the Certificates snap-in console. If you have not previously added in the Certificates snap-in console, you can achieve this by doing the following: Ã¢Â€Â¢Click Start, select Run, type mmc, and then tap OK. Ã¢Â€Â¢On the File menu, choose Add/Remove Snap-in. Ã¢Â€Â¢In the Add or Remove Snap-ins dialog box, in the Available snap-ins file, choose Certificates, and then click Add. Ã¢Â€Â¢In the Certificates snap-in dialog box, select Computer account, and at that time click Next. Ã¢Â€Â¢In the Select Computer dialog box, click Local computer: (the computer this console is running on), followed by selecting Finish. Ã¢Â€Â¢In the Add or Remove snap-ins dialog box, click OK. 2.In the Certificates snap-in console, in the console tree, double click to show more items on Certificates (Local Computer), repeat previous step with Trusted Root Certification Authorities, right-click Certificates, and focus on All Tasks, followed by selecting Import. 3.Once you get to the Welcome to the Certificate Import Wizard page, select Next. 4.On the File to Import page, in the File name box, indicate the title of the server root certificate, then select Next. 5.On the Password page, if you created a pass phrase for the private key linked with the certificate previously, enter the pass phrase. 6.On the Certificates Store page, allow the default selection (Place all certificates in the following store Ã¢Â€Â“ Trusted Root Certification Authorities), followed by choosing Next. 7.On the Completing the Certificate Import Wizard page, verify that the certificate settings appear as followed: Ã¢Â€Â¢Certificate Store Selected by User: Trusted Root Certification Authorities Ã¢Â€Â¢Content: Certificate Ã¢Â€Â¢File Name: FilePath\<root_certificate_name.cer>, where <root_certificate_name> is the name of the server root certificate. 8.Select Finish. 9.Once the certificate upload has successfully concluded, a confirmation message will show up proving the import was successful. Select OK. 10.With Certificates chosen in the console hierarchy, in the detail panel, confirm that the root certificate of the server has become visible in the file of certificates on the client. This process can be modified on client computers to use website certificates, remote desktop certificates, and Exchange certificates. Shawn Zernik www.internetworkconsulting.net
S.M. RAKIBUL ISLAM(2014-12-13)
HI
Benjamin(2014-12-13)
When I first read this I was mislead in to thinking that a self signed certificate leaves the connection vulnerable to attack by someone other than the certificate issuer e.g. site owner. This seemed wrong to me so I investigated and found that it is only the identity that is not verified by a certificate authority not that the certificated connection is any less secure. Just thought I would clear this up in case anyone else was as confused.
Quanterum(2016-08-31)
The connection is actually less secure because the attacker just needs to duplicate (re-create) the self signed cert. I the attacker can set up a server to intercept traffic heading to your site, using the exact same details of your self signed cert on my malicious website that poses to be yours. Users think that they are at your site, providing login credentials, that I intercept, and forward to your original site. This is a total compromise... Therefore, the connection is less secure as originally stated. This is performed because there is no Certification Authority involved, there is no 'trust anchor'. The trust anchor is a way in which each certificate is proven to be authentic. This removes duplicate certs getting created. With self-signed certs there is no trust anchor. Cheers
IT Guy(2016-09-29)
You won't be able to do man-in-the-middle with self sign certs anymore than CA signed cert. As long as the private key is kept as secure as you would in a CA issued cert, you won't be able to match digital signatures by doing man-in-the-middle as you do not possess the original private key. CA issued certs allow the browser to recognize that the issuing authority is trusted but as long as the same key length and ciphers are used, the self signed certs as as secure as CA signed. I agree that CA signed certs must be used for external facing systems where end users would use a standard browser that only trusts CA's and their generated certs.
SSL Shopper(2016-09-30)
You're right that self-signed certificates enable the same encryption that a CA-signed cert does and they can be just as secure if deployed properly. But there are vulnerabilities that have to be taken into account. Specifically, users have to receive the certificate in a secure way the first time and the software needs to warn if the certificate is different. Otherwise a man-in-the-middle could present their own self-signed certificate and the user would have no way to tell the difference between it and the real one. And, unfortunately, modern web browsers aren't set up to work this way currently which is why a CA-signed certificate is required in most situations. This article has some more details about how to use self-signed certificates securely: http://www.clintharris.net/...
Robert(2014-12-13)
Hi Hany, The "title of the server root certificate" is the filename of the Root Certificate that you created.
Hany(2014-12-13)
in the 4th step, from where can I find this name "indicate the title of the server root certificate" ?
Dharmender Singh(2015-11-21)
Hi, I need to export the certificates chain (including root, intermediate and signed certificate) using Keytool from one server and will be imported to another server. If someone can help me with the steps and the commands, I would need to follow to accomplish this would be really appreciated. Also, if I copy the keystore from one server and paste it another server on its path, will it work since keystore and common name are same?
Willhelm(2016-07-19)
The SSL/TLS protocol is used for the encrypted communication, but TLS will not be secure unless the infrastructure is based on trusted X.509 certificates. This trust is the key component required for TLS to be secure. For this reason, it is important to install a certificate in the server that is trusted by all of the client's connected to the server. Instead of creating a self signed certificate, create a self signed CA (root) certificate and use this certificate to sign your certificates. The root certificate can then optionally be installed in the clients/computers/browsers, thus making the certificate trusted -- that is, you will not get the certificate warning in the browser. There's an easy to use GUI tool you can run on your own computer, which uses OpenSSL, and that makes the certificate chain process creation very easy to perform. See the following for details: https://realtimelogic.com/b...
Soma Ghosh(2018-11-30)
I implemented the above process so many times to create certificate. Latter on I found the easy way to do that. You also check the below article https://www.seoexpertstuff....

Save