From 001fbf5499b6d9524122e719af054ae4c10df266 Mon Sep 17 00:00:00 2001 From: Thomas Preud'homme Date: Sat, 3 May 2014 16:47:39 +0800 Subject: [PATCH] [ssl_mgmt] Add debian-admin openssl howto Add debian-admin article used as main documentation for developing this script into the repository to be able to develop offline. --- ssl_mgmt/debian-admin_openssl_howto.html | 3483 ++++++++++++++++++++++ 1 file changed, 3483 insertions(+) create mode 100644 ssl_mgmt/debian-admin_openssl_howto.html diff --git a/ssl_mgmt/debian-admin_openssl_howto.html b/ssl_mgmt/debian-admin_openssl_howto.html new file mode 100644 index 0000000..980b853 --- /dev/null +++ b/ssl_mgmt/debian-admin_openssl_howto.html @@ -0,0 +1,3483 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + Creating and Using a self signed SSL Certificates in debian + + + + + + + + + + + + + + + + + + + +
+
+
+
+
+ + + + + + +
+ +

Creating and Using a self signed SSL Certificates in debian

+ +

Posted by Marcus_Redivo on Thu 3 Nov 2005 at 12:30

+ + + + +
+ Tags: + +, + +, + +, + +, + +, + +, + + + + + +
+ + + +

This document covers a very specific, limited purpose, but one that meets a common need: preventing browser, mail, and other clients from complaining about the certificates installed on your server. Not covered is dealing with a commercial root certificate authority (CA). Instead, we will become our own root CA, and sign our own certificates.

+

(These procedures were developed using OpenSSL 0.9.6.)

+Quick Start +

Those who want to start creating certificates right away without reading this whole document should skip to the summary at the end.

+

Note: a self-signed cert can be created with the simple command mod-ssl-makecert, part of the Debian package libapache-mod-ssl.

+ + +Background +
+

Why be our own root CA? So that we can take advantage of SSL encryption without spending unnecessary money on having our certificates signed.

+

A drawback is that browsers will still complain about our site not being trusted until our root certificate is imported. However, once this is done, we are no different from the commercial root CAs.

+

Clients will only import our root certificate if they trust us. This is where the commercial CAs come in: they purport to do extensive research into the people and organizations for whom they sign certificates. By importing (actually, by the browser vendors incorporating) their trusted root certificates, we are saying that we trust them when they guarantee that someone else is who they say they are. We can trust additional root CAs (like ourselves) by importing their CA certificates.

+

Note: If you are in the business of running a commercial secure site, obtaining a commercially signed certificate is the only realistic choice.

+
+ +Prerequisites +
+

You will need an installed copy of OpenSSL for this, which is available from http://www.openssl.org/ Chances are it is already installed on your machine. This document will not cover the installation procedure. +

+> apt-get install openssl 
+
+
+ +Initial Setup +
+

First, we will create a directory where we can work. It does not matter where this is; I am arbitrarily going to create it in my home directory.

+ +
+mkdir CA 
+cd CA 
+mkdir newcerts private 
+
+

The CA directory will contain:

+
    +
  • Our Certificate Authority (CA) certificate
    • +
  • The database of the certificates that we have signed
    • +
  • The keys, requests, and certificates we generate
    • +
+

It will also be our working directory when creating or signing certificates.

+

The CA/newcerts directory will contain:

+
    +
  • A copy of each certificate we sign
    • +
+

The CA/private directory will contain:

+
    +
  • Our CA private key
    • +
+

This key is important - Do not lose this key. Without it, you will not be able to sign or renew any certificates. Do not disclose this key to anyone. If it is compromised, others will be able to impersonate you.

+

Our next step is to create a database for the certificates we will sign:

+
+echo '01' > serial 
+touch index.txt 
+
+

Rather than use the configuration file that comes with OpenSSL, we are going to create a minimal configuration of our own in this directory. Start your editor (vi, pico, ...) and create a basic openssl.cnf:

+
+# 
+# OpenSSL configuration file. 
+# 
+
+# Establish working directory. 
+dir = . 
+
+
+ + +Creating a Root Certificate +
+

With OpenSSL, a large part of what goes into a certificate depends on the contents of the configuration file, rather than the command line. This is a good thing, because there is a lot to specify.

+

The configuration file is divided into sections, which are selectively read and processed according to openssl command line arguments. Sections can include one or more other sections by referring to them, which helps to make the configuration file more modular. A name in square brackets (e.g. " req ") starts each section.

+

We now need to add the section that controls how certificates are created, and a section to define the type of certificate to create.

+

The first thing we need to specify is the Distinguished Name. This is the text that identifies the owner of the certificate when it is viewed. It is not directly referenced in the configuration file, but is included into the section processed when certificate requests are created. The command is "openssl req", so the section is titled req.

+

Add the following to openssl.cnf:

+
+
+[ req ] 
+default_bits = 1024 # Size of keys 
+default_keyfile = key.pem # name of generated keys 
+default_md = md5 # message digest algorithm 
+string_mask = nombstr # permitted characters 
+distinguished_name = req_distinguished_name 
+
+[ req_distinguished_name ] 
+# Variable name   Prompt string 
+#----------------------   ---------------------------------- 
+0.organizationName = Organization Name (company) 
+organizationalUnitName = Organizational Unit Name (department, division) 
+emailAddress = Email Address 
+emailAddress_max = 40 
+localityName = Locality Name (city, district) 
+stateOrProvinceName = State or Province Name (full name) 
+countryName = Country Name (2 letter code) 
+countryName_min = 2 
+countryName_max = 2 
+commonName = Common Name (hostname, IP, or your name) 
+commonName_max = 64 
+
+# Default values for the above, for consistency and less typing. 
+# Variable name   Value 
+#------------------------------   ------------------------------ 
+0.organizationName_default = The Sample Company 
+localityName_default = Metropolis 
+stateOrProvinceName_default = New York 
+countryName_default = US 
+
+[ v3_ca ] 
+basicConstraints = CA:TRUE 
+subjectKeyIdentifier = hash 
+authorityKeyIdentifier = keyid:always,issuer:always 
+
+ +

In order to protect ourselves from unauthorized use of our CA certificate, it is passphrase protected. Each time you use the CA certificate to sign a request, you will be prompted for the passphrase. Now would be a good time to pick a secure passphrase and put it in a safe place.

+

All the preparation is now in place for creating our self-signed root certificate. For this, we want to override some of the defaults we just put into the configuration, so we will specify our overrides on the command line.

+

Our overrides to the "openssl req" command are:

+

Create a new self-signed certificate: "-new -x509".

+

Create a CA certificate: "-extensions v3_ca ".

+

Make it valid for more than 30 days: -"days 3650 ".

+

Write output to specific locations: "-keyout, -out ".

+

Use our configuration file: "-config ./openssl.cnf ".

+

(A note on the term of validity of root certificates: When a root certificate expires, all of the certificates signed with it are no longer valid. To correct this situation, a new root certificate must be created and distributed. Also, all certificates signed with the expired one must be revoked, and re-signed with the new one. As this can be a lot of work, you want to make your root certificate valid for as long as you think you will need it. In this example, we are making it valid for ten years.)

+

Run the command as shown. In this case, the PEM pass phrase it asks for is a new one, which you must enter twice:

+
+
+# openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem \ 
+-out cacert.pem -days 3650 -config ./openssl.cnf 
+Using configuration from ./openssl.cnf 
+Generating a 1024 bit RSA private key 
+.......++++++ 
+..........................++++++ 
+writing new private key to 'private/cakey.pem' 
+Enter PEM pass phrase:demo 
+Verifying password - Enter PEM pass phrase:demo 
+----- 
+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. 
+----- 
+Organization Name (company) [The Sample Company]: 
+Organizational Unit Name (department, division) []:CA Division 
+Email Address []:ca@sample.com 
+Locality Name (city, district) [Metropolis]: 
+State or Province Name (full name) [New York]: 
+Country Name (2 letter code) [US]: 
+Common Name (hostname, IP, or your name) []:TSC Root CA 
+
+
+

This process produces two files as output:

+
    +
  • A private key in private/cakey.pem .
    • +
  • A root CA certificate in cacert.pem.
    • +
+

cacert.pem is the file you want to distribute to your clients.

+

The private key (cakey.pem) looks like this:

+
+-----BEGIN RSA PRIVATE KEY----- 
+Proc-Type: 4,ENCRYPTED 
+DEK-Info: DES-EDE3-CBC,0947F49BB28FE5F4 
+
+jlQvt9WdR9Vpg3WQT5+C3HU17bUOwvhp/r0+viMcBUCRW85UqI2BJJKTi1IwQQ4c 
+tyTrhYJYOP+A6JXt5BzDzZy/B7tjEMDBosPiwH2m4MaP+6wTbi1qR1pFDL3fXYDr 
+ZsuN08dkbw9ML6LOX5Rl6bIBL3i5hnGiqm338Fl52gNstThv0C/OZhXT3B4qsJn8 
+qZb3mC6U2nRaP/NpZPcEx4lv2vH7OzHTu1TZ7t0asSpgpuH58dfHPw775kZDep2F 
+LXA3Oeavg0TLFHkaFBUx2xaeEG6Txpt9I74aAsw1T6UbTSjqgtsK0PHdjPNfPGlY 
+5U3Do1pnU9hfoem/4RAOe0cCovP/xf6YPBraSFPs4XFfnWwgEtL09ReFqO9T0aSp 
+5ajLyBOYOBKQ3PCSu1HQDw/OzphInhKxdYg81WBBEfELzSdMFQZgmfGrt5DyyWmq 
+TADwWtGVvO3pEhO1STmCaNqZQSpSwEGPGo5RFkyFvyvyozWX2SZg4g1o1X40qSg9 
+0FMHTEB5HQebEkKBoRQMCJN/uyKXTLjNB7ibtVbZmfjsi9oNd3NJNVQQH+o9I/rP 
+wtFsjs+t7SKrsFB2cxZQdDlFzD6EBA+5ytebGEI1lJHcOUEa6P+LTphlwh/o1QuN 
+IKX2YKHA4ePrBzdgZ+xZuSLn/Qtjg/eZv6i73VXoHk8EdxfOk5xkJ+DnsNmyx0vq 
+W53+O05j5xsxzDJfWr1lqBlFF/OkIYCPcyK1iLs4GOwe/V0udDNwr2Uw90tefr3q 
+X1OZ9Dix+U0u6xXTZTETJ5dF3hV6GF7hP3Tmj9/UQdBwBzr+D8YWzQ== 
+-----END RSA PRIVATE KEY----- 
+
+

Of course, you don't want to show this to anyone! Needless to say, the one shown here is now useless as a private key.

+

The certificate (cacert.pem) looks like this:

+
+-----BEGIN CERTIFICATE----- 
+MIIDrTCCAxagAwIBAgIBADANBgkqhkiG9w0BAQQFADCBnDEbMBkGA1UEChMSVGhl 
+IFNhbXBsZSBDb21wYW55MRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEcMBoGCSqGSIb3 
+DQEJARYNY2FAc2FtcGxlLmNvbTETMBEGA1UEBxMKTWV0cm9wb2xpczERMA8GA1UE 
+CBMITmV3IFlvcmsxCzAJBgNVBAYTAlVTMRQwEgYDVQQDEwtUU0MgUm9vdCBDQTAe 
+Fw0wMTEyMDgwNDI3MDVaFw0wMjEyMDgwNDI3MDVaMIGcMRswGQYDVQQKExJUaGUg 
+U2FtcGxlIENvbXBhbnkxFDASBgNVBAsTC0NBIERpdmlzaW9uMRwwGgYJKoZIhvcN 
+AQkBFg1jYUBzYW1wbGUuY29tMRMwEQYDVQQHEwpNZXRyb3BvbGlzMREwDwYDVQQI 
+EwhOZXcgWW9yazELMAkGA1UEBhMCVVMxFDASBgNVBAMTC1RTQyBSb290IENBMIGf 
+MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDaiAwfKB6ZBtnTRTIo6ddomt0S9ec0 
+NcuvtJogt0s9dXpHowh98FCDjnLtCi8du6LDTZluhlOtTFARPlV/LVnpsbyMCXMs 
+G2qpdjJop+XIBdvoCz2HpGXjUmym8WLqt+coWwJqUSwiEba74JG93v7TU+Xcvc00 
+5MWnxmKZzD/R3QIDAQABo4H8MIH5MAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFG/v 
+yytrBtEquMX2dreysix/MlPMMIHJBgNVHSMEgcEwgb6AFG/vyytrBtEquMX2drey 
+six/MlPMoYGipIGfMIGcMRswGQYDVQQKExJUaGUgU2FtcGxlIENvbXBhbnkxFDAS 
+BgNVBAsTC0NBIERpdmlzaW9uMRwwGgYJKoZIhvcNAQkBFg1jYUBzYW1wbGUuY29t 
+MRMwEQYDVQQHEwpNZXRyb3BvbGlzMREwDwYDVQQIEwhOZXcgWW9yazELMAkGA1UE 
+BhMCVVMxFDASBgNVBAMTC1RTQyBSb290IENBggEAMA0GCSqGSIb3DQEBBAUAA4GB 
+ABclymJfsPOUazNQO8aIaxwVbXWS+8AFEkMMRx6O68ICAMubQBvs8Buz3ALXhqYe 
+FS5G13pW2ZnAlSdTkSTKkE5wGZ1RYSfyiEKXb+uOKhDN9LnajDzaMPkNDU2NDXDz 
+SqHk9ZiE1boQaMzjNLu+KabTLpmL9uXvFA/i+gdenFHv 
+-----END CERTIFICATE----- 
+
+

We can query the contents of this certificate with openssl to learn to whom belongs, what it is valid for, etc.:

+
+openssl x509 -in cacert.pem -noout -text 
+openssl x509 -in cacert.pem -noout -dates 
+ openssl x509 -in cacert.pem -noout -purpose 
+
+
+ + +Creating a Certificate Signing Request (CSR) +
+

Now that we have a root certificate, we can create any number of certificates for installation into our SSL applications such as HTTPS, SPOP, or SIMAP. The procedure involves creating a private key and certificate request, and then signing the request to generate the certificate.

+

Our configuration file needs some more definitions for creating non-CA certificates. Add the following at the end of the file:

+
+[ v3_req ] 
+basicConstraints = CA:FALSE 
+subjectKeyIdentifier = hash 
+
+

To avoid having to repeatedly put this on the command line, insert the following line to the req section after the distinguished_name line as shown:

+
+distinguished_name = req_distinguished_name 
+req_extensions = v3_req 
+
+

Now we are ready to create our first certificate request. In this example, we are going to create a certificate for a secure POP server at mail.sample.com. Everything looks the same as when we created the CA certificate, but three of the ensuing prompts get different responses.

+
+Organizational Unit: a reminder of what the certificate is for 
+Email Address: the postmaster 
+Common Name: the server hostname
+
+

The Common Name must be (or the IP address must resolve to) the server name your clients use to contact your host. If this does not match, every time they connect your clients will get a message asking them if they want to use this server. In effect, the client software is saying:

+
+"Warning! You asked for mail.sample.com; the responding machine's certificate is for smtp.sample.com. Are you sure you want to continue?" +
+ +
+openssl req -new -nodes -out req.pem -config ./openssl.cnf 
+
+Organizational Unit Name (department, division) :Mail Server Email Address :postmaster@sample.com 
+Common Name (hostname, IP, or your name) :mail.sample.com 
+
+

This process produces two files as output:

+
    +
  • A private key in key.pem
    • +
  • A certificate signing request in req.pem
    • +
+

These files should be kept. When the certificate you are about to create expires, the request can be used again to create a new certificate with a new expiry date. The private key is of course necessary for SSL encryption. When you save these files, meaningful names will help; for example, mailserver.key.pem and mailserver.req.pem..

+

The certificate signing request looks like this:

+
+-----BEGIN CERTIFICATE REQUEST----- 
+MIICJDCCAY0CAQAwgagxGzAZBgNVBAoTElRoZSBTYW1wbGUgQ29tcGFueTEUMBIG 
+A1UECxMLTWFpbCBTZXJ2ZXIxJDAiBgkqhkiG9w0BCQEWFXBvc3RtYXN0ZXJAc2Ft 
+cGxlLmNvbTETMBEGA1UEBxMKTWV0cm9wb2xpczERMA8GA1UECBMITmV3IFlvcmsx 
+CzAJBgNVBAYTAlVTMRgwFgYDVQQDEw9tYWlsLnNhbXBsZS5jb20wgZ8wDQYJKoZI 
+hvcNAQEBBQADgY0AMIGJAoGBAPJhc++WxcBaoDbJpzFbDg42NcOz/ELVFMU4FlPa 
+yUzUO+xXkdFRMPKo54d4Pf1w575Jhlu9lE+kJ8QN2st6JFySbc9QjPwVwl9D2+I3 
+SSf2kVTu+2Ur5izCPbVAfU0rPZxxK8ELoOkA1uwwjFz6EFuVvnHwlguonWKDtmYW 
+u7KTAgMBAAGgOzA5BgkqhkiG9w0BCQ4xLDAqMAkGA1UdEwQCMAAwHQYDVR0OBBYE 
+FLWaQsUVIQzWr58HtDinH1JfeCheMA0GCSqGSIb3DQEBBAUAA4GBAAbe0jrGEQ3i 
+tyVfy5Lg4/f69rKvDGs+uhZJ9ZRx7Dl92Qq2osE7XrLB1bANmcoEv/ORLZOjWZEY 
+NjMvuz60O7R8GKBrvb/YhAwWhIIt2LJqPkpAEWS0kY0AkoQcfZ7h6oC35+eJ7okg 
+Uu3WuE57RgcNt7/ftr0sG1jUyRwMLvhv 
+-----END CERTIFICATE REQUEST----- 
+
+

We can view the contents to make sure our request is correct:

+
+openssl req -in req.pem -text -verify -noout 
+
+
+ + +Signing a Certificate +
+

Now we need to add the configuration file section that deals with being a Certificate Authority. This section will identify the paths to the various pieces, such as the database, the CA certificate, and the private key. It also provides some basic default values. Insert the following into openssl.cnf just before the req section:

+
+[ ca ] 
+default_ca = CA_default 
+
+[ CA_default ] 
+serial = $dir/serial 
+database = $dir/index.txt 
+new_certs_dir = $dir/newcerts 
+certificate = $dir/cacert.pem 
+private_key = $dir/private/cakey.pem 
+default_days = 365 
+default_md = md5 
+preserve = no 
+email_in_dn = no 
+nameopt = default_ca 
+certopt = default_ca 
+policy = policy_match 
+
+[ policy_match ] 
+countryName = match 
+stateOrProvinceName = match 
+organizationName = match 
+organizationalUnitName = optional 
+commonName = supplied 
+emailAddress = optional 
+
+

To sign the request we made in the previous step, execute the following and respond to the prompts. Note that you are asked for the PEM passphrase selected earlier:

+
+openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem 
+Using configuration from ./openssl.cnf 
+Enter PEM pass phrase:demo 
+Check that the request matches the signature 
+Signature ok 
+The Subjects Distinguished Name is as follows 
+organizationName      :PRINTABLE:'The Sample Company' 
+organizationalUnitName:PRINTABLE:'Mail Server' 
+emailAddress          :IA5STRING:'postmaster@sample.com' 
+localityName          :PRINTABLE:'Metropolis' 
+stateOrProvinceName   :PRINTABLE:'New York' 
+countryName           :PRINTABLE:'US' 
+commonName            :PRINTABLE:'mail.sample.com' 
+Certificate is to be certified until Dec  8 04:37:38 2002 GMT (365 days) 
+Sign the certificate? [y/n]:y 
+
+1 out of 1 certificate requests certified, commit? [y/n]y 
+Write out database with 1 new entries 
+Data Base Updated 
+
+

This process updates the CA database, and produces two files as output:

+
    +
  • A certificate in cert.pem
    • +
  • A copy of the certificate in newcerts/.pem
    • +
+

Again, you can inspect the certificate:

+
+openssl x509 -in cert.pem -noout -text -purpose | more 
+
+

The certificate has both the encoded version and a human-readable version in the same file. You can strip off the human-readable portion as follows:

+
+mv cert.pem tmp.pem 
+openssl x509 -in tmp.pem -out cert.pem 
+
+
+ + +Installing the Certificate and Key +
+

This depends on the application. Some want the key and the certificate in the same file, and others want them separately. Combining them is easily done with:

+
+cat key.pem cert.pem >key-cert.pem 
+
+

After this step, you have three installable components to choose from:

+
    +
  • A private key in key.pem.
    • +
  • A certificate in cert.pem.
    • +
  • A combined private key and certificate in key-cert.pem .
    • +

    Copy the appropriate files into the locations specified by the instructions for your application and system. Restart the applications, and you are in operation with your new certificate.

    + +Apache +
    +

    Apache has separate configuration directives for the key and the certificate, so we keep each in its own file. These files should be kept outside of the DocumentRoot subtree, so a reasonable directory structure might be:

    +
    +File          Comment 
+/home/httpd/html Apache DocumentRoot 
+/home/httpd/ssl      SSL-related files 
+/home/httpd/ssl/cert.pem Site certificate 
+/home/httpd/ssl/key.pem Site private key 
+
    +

    Within the directive for the site (which of course should be on port 443), include the directives that point to these files:

    +
    +    ServerName mail.sample.com 
+   DocumentRoot /home/httpd/html 
+   ... other directives for this site ... 
+   SSLEngine on 
+   SSLLog /var/log/ssl_engine_log 
+   SSLCertificateFile /home/httpd/ssl/cert.pem 
+   SSLCertificateKeyFile /home/httpd/ssl/key.pem 
+
    +
    + +Stunnel +
    +

    stunnel is used as an SSL wrapper for normal non-secure services such as IMAP and POP. It accepts as arguments (among other things) the service to execute, and the location of the certificate and private key.

    +

    The key and the certificate are provided in the same file. These can go anywhere, but a good location might be /etc/ssl/certs. Specify it on the stunnel command line as follows: +

    +stunnel -p /etc/ssl/certs/key-cert.pem  
+
    +
    +
+ +Distributing the CA Certificate +
+

This, finally, is the step that stops the clients from complaining about untrusted certificates. Send cacert.pem to anyone who is going to use your secure servers, so they can install it in their browsers, mail clients, et cetera as a root certificate.

+
+ +Renewing Certificates +
+

Your certificate chain can break due to certificate expiry in two ways:

+
    +
  • The certificates you signed with your root certificate have expired.
    • +
  • Your root certificate itself has expired.
    • +
+

In the second case, you have some work to do. A new root CA certificate must be created and distributed, and then your existing certificates must be recreated or re-signed.

+

In the first case, you have two options. You can either generate new certificate signing requests and sign them as described above, or (if you kept them) you can re-sign the original requests. In either case, the old certificates must be revoked, and then the new certificates signed and installed into your secure applications as described earlier.

+

You cannot issue two certificates with the same Common Name, which is why the expired certificates must be revoked. The certificate is in the newcerts directory; you can determine its filename by browsing index.txt and searching for the Common Name (CN) on it. The filename is the index plus the extension ".pem", for example "02.pem". To revoke a certificate:

+
+openssl ca -revoke newcerts/02.pem -config ./openssl.cnf 
+Using configuration from ./openssl.cnf 
+Enter PEM pass phrase: demo 
+Revoking Certificate 02. 
+Data Base Updated 
+
+

Now that the certificate has been revoked, you can re-sign the original request, or create and sign a new one as described above.

+
+ +Getting a Commercially Signed Certificate +
+

The process is basically the same as the one just demonstrated, but the CA does most of it. You need to generate a Certificate Signing Request as shown above, and then submit it for signing. You will receive a signed certificate for installation.

+

This certificate will automatically be trusted by your client's browser, as the browser has the commercial CA's certificate built in. There is no need to distribute anything.

+

The configuration described here may be inadequate for this purpose, as there is much more that can go into a request. Different certificate authorities require different features in the certificate signing request, none of which we have gone into here. This additional material is beyond the current scope of this document.

+
+ +Publishing Your CA Certificate +
+

You can post the certificate on your web site for download. If you do this, you should also post a Certificate Revocation List (CRL), and a means of displaying a certificate given its serial number. This is outside the current scope of this document.

+

Apache will serve your certificate in a form recognizable to browsers if you specify its MIME type. For example, you can use the filename extension ".crt" for downloadable certificates, and put the following into the general section of your Apache configuration:

+
+AddType application/x-x509-ca-cert .crt 
+
+

Now you can post the certificate for download with a link like +Our Root Certificate

+

and when the link is followed the visitor's browser would offer to install the certificate.

+

The CRL can be created as follows:

+
+openssl ca -gencrl -crldays 31 -config ./openssl.cnf -out rootca.crl 
+
+
+ +Summary +
+

You now have enough information to create and sign certificates on your own behalf. While this is a fairly long document, the procedure can be summarized easily.

+ + +One-Time Setup +

Set up, and create a root CA certificate. Commands:

+
+# mkdir CA 
+# cd CA 
+# mkdir newcerts private 
+# echo '01' >serial 
+# touch index.txt 
+# (IMPORTANT: Install and edit the configuration file shown below.) 
+# openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem \ 
+-out cacert.pem -days 365 -config ./openssl.cnf 
+
+

Output :

+
    +
  • cacert.pem - CA certificate
    • +
  • private/cakey.pem - CA private key
    • +
+

Distribute cacert.pem to your clients.

+ +Per Certificate +

Create certificate signing requests and sign them, supplying appropriate values for the Common Name and the Organizational Unit.

+

Commands :

+
+openssl req -new -nodes -out req.pem -config ./openssl.cnf 
+openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem 
+cat key.pem cert.pem >key-cert.pem 
+
+

Output :

+
    +
  • key.pem - Private key
    • +
  • req.pem - Certificate signing request
    • +
  • cert.pem - Certificate
    • +
  • key-cert.pem - Combined private key and certificate
    • +
+

Install key.pem and cert.pem, or just key-cert.pem as appropriate for your server application.

+Per Certificate - Renewal +

Revoke the expired certificate, and re-sign the original request. +

Commands :

+
+openssl ca -revoke newcerts/.pem -config ./openssl.cnf 
+openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem 
+
+

Install the renewed certificates in the same manner as the original ones.

+

Configuration File

+
+# 
+# OpenSSL configuration file. 
+# 
+
+# Establish working directory. 
+
+dir = . 
+
+[ ca ] 
+default_ca = CA_default 
+
+[ CA_default ] 
+serial = $dir/serial 
+database = $dir/index.txt 
+new_certs_dir = $dir/newcerts 
+certificate = $dir/cacert.pem 
+private_key = $dir/private/cakey.pem 
+default_days = 365 
+default_md = md5 
+preserve = no 
+email_in_dn = no 
+nameopt = default_ca 
+certopt = default_ca 
+policy = policy_match 
+
+[ policy_match ] 
+countryName = match 
+stateOrProvinceName = match 
+organizationName = match 
+organizationalUnitName = optional 
+commonName = supplied 
+emailAddress = optional 
+
+[ req ] 
+default_bits = 1024 # Size of keys 
+default_keyfile = key.pem # name of generated keys 
+default_md = md5 # message digest algorithm 
+string_mask = nombstr # permitted characters 
+distinguished_name = req_distinguished_name 
+req_extensions = v3_req 
+
+[ req_distinguished_name ] 
+# Variable name   Prompt string 
+#----------------------   ---------------------------------- 
+0.organizationName = Organization Name (company) 
+organizationalUnitName = Organizational Unit Name (department, division) 
+emailAddress = Email Address 
+emailAddress_max = 40 
+localityName = Locality Name (city, district) 
+stateOrProvinceName = State or Province Name (full name) 
+countryName = Country Name (2 letter code) 
+countryName_min = 2 
+countryName_max = 2 
+commonName = Common Name (hostname, IP, or your name) 
+commonName_max = 64 
+
+# Default values for the above, for consistency and less typing. 
+# Variable name   Value 
+#------------------------------   ------------------------------ 
+0.organizationName_default = The Sample Company 
+localityName_default = Metropolis 
+stateOrProvinceName_default = New York 
+countryName_default = US 
+
+[ v3_ca ] 
+basicConstraints = CA:TRUE 
+subjectKeyIdentifier = hash 
+authorityKeyIdentifier = keyid:always,issuer:always 
+
+[ v3_req ] 
+basicConstraints = CA:FALSE 
+subjectKeyIdentifier = hash 
+
+
+
+ +

Updated: 9th November 2005

+
+

It has been brought to my attention that this article has been plagiarized by the poster who claimed it as his own work. That poster has now has his accoutn suspended.

+

The original author of the article, Marcus Redivo, has kindly allowed the text to remain on this site. The original article as written by Marcus can be found upon his website here:

+ +
+ + + +
+
+ + +
+
+ + Add Comment + XML logo + + Printable version + +
+
+ + +

 

+
+ + + <<< Denying access to your web server by IP address + + + + + WebDAV on Apache2 >>> + + +
+
+ +
+
+ +

 

+ +

 

+ + + + +

+ + + + + +
+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by simonw (84.45.xx.xx) on Thu 3 Nov 2005 at 16:06
+[ Send Message | View Weblogs ]
+ +
+ > Note: If you are in the business of running a commercial secure site, obtaining a commercially signed certificate is the only realistic choice.

Depends entirely on the sophistication of your userbase.

Paul Vixie ignored this advice when involved with setting up mail-abuse.org, because all the major commercial certificate vendors were also involved in the spam business, the others authorities expect you to be a bank, or have other weird qualifying criteria.

Guess a case of being wary who you do business with.

Thanks for the article, I've used similar articles in the past, and hope the Debian specific one will save me some more time next time I need a self signed certificate. +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (128.250.xx.xx) on Fri 4 Nov 2005 at 01:07
+
+ +
+ Wonderful article... I've been through a world of pain trying to do this a couple of times and then once I finally thought I'd got it right I realised that the damned certificate didn't have a serial so renewing it was almost impossible with some brain dead browsers.

Definitely an article that I'll keep in a safe place until I next have to do this (about once every 2 or 3 years... just enough time to forget all the mistakes you made last time!)

thanks!!! +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by dkg (216.254.xx.xx) on Fri 4 Nov 2005 at 04:20
+[ Send Message | View dkg's Scratchpad | View Weblogs ]
+ +
+ Awesome article. Thanks for collecting all these pieces in a single place.

I've found that tinyca (debian package info) is a decent tool for prompting you for most of the relevant pieces of information you might need, especially if signing cert requests is something you do infrequently enough that you forget the exact details. A good secure configuration is to run tinyCA on a dedicated old machine which never connects to the net. You can then import the certificate requests with a USB key or floppy disk, sign them on the isolated machine, and return the new certs via the same removable medium.

To future-proof your article: you might want to consider increasing the default bit length of your keypair in openssl.cnf, assuming your TLS-enabled server is running reasonable hardware. openssh (which uses different PKI infrastructure, but similar math) just increased default key length to 2048 with version 4.2.

The one final missing piece would be to write up something comparably detailed about Certificate Revocation and how to manage, create, and distribute Certificate Revocation Lists using debian tools. if i get a chance, i'll try to write up something on that for this site. +

+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (217.11.xx.xx) on Fri 4 Nov 2005 at 12:20
+
+ +
+ Fantastic article. Thanks! +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Arto (213.250.xx.xx) on Fri 4 Nov 2005 at 16:51
+[ Send Message ]
+ +
+

Thanks for article, that came in handy as I'm just finishing setting up a new Debian server and will need to create the SSL certificates next.

It's amazing, though, how difficult providing an encrypted data channel has been made; no doubt the problem lies in the fact that certificates try to go beyond just encryption, and provide some unrealistic measure of "trust" as well. Well, it's a good business to some, that's for sure.

It's been a while since I played around with these things, so just one question:

The Common Name must be (or the IP address must resolve to) the server name your clients use to contact your host. If this does not match, every time they connect your clients will get a message asking them if they want to use this server.

Does this mean that if I create a CSR bound to an IP address instead of a host name, the clients won't get any complaints regardless of the host name (smtp.sample.com, mail.sample.com, or so forth) they use to access the server, as long as the host names resolve to the same IP? +

+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + +
+ + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (66.43.xx.xx) on Mon 12 Jun 2006 at 13:52
+
+ +
+ I have come across cases where the CSR was bound to an IP instead of the host name and I did get a complaint.
+
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + +
+ + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (213.219.xx.xx) on Sat 5 Nov 2005 at 18:13
+
+ +
+ I created a certificate for my server using www.cacert.org. It is not accepted by default in browser as a valid authority but it may be sometime. +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + +
+ + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (195.14.xx.xx) on Tue 8 Nov 2005 at 13:28
+
+ +
+ check the ports.conf file did you changed the port number or not +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + +
+ + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by timt (217.13.xx.xx) on Wed 9 Nov 2005 at 00:29
+[ Send Message ]
+ +
+ Good article, very useful. But I feel I have read it before somewhere. +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + +
+ + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Steve (82.41.xx.xx) on Wed 9 Nov 2005 at 05:18
+[ Send Message | View Steve's Scratchpad | View Weblogs ]
+ +
+

I had no idea it was copied. I trust that people will play fair and not claim credit they do not deserve.

Marcus got in touch with me to confirm this was a copy of his work. He has graciously allowed it to remain here - and I've banned the original "author".

Right about now I have very little faith in peoples honesty.

Steve
-- +

+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + +
+ + + +

+ + + + + +
+ + +
+ + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Marcus_Redivo (139.142.xx.xx) on Wed 9 Nov 2005 at 19:20
+[ Send Message ]
+ +
+

Steve wrote:

> Right about now I have very little faith in peoples honesty.

And right about now, I do.

I sent a note to the site Webmaster (Steve) when I became aware that my document had been posted by someone under their own name.

Steve went way beyond the call of duty in responding and doing the right thing. By the time I finished reading my email, I already had a note from Steve in my inbox, and the offending account had been suspended. I indicated in my response that Steve was welcome to keep the content up; after all, it was written to be read.

Many thanks, Steve, for making this right. You are the kind of person that makes the Internet a nice place, and I'm sure you also do this in person in your community.

Best regards,
Marcus +

+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + +
+ + +
+ + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (62.89.xx.xx) on Thu 10 Nov 2005 at 14:06
+
+ +
+ Nice article to explain the basics.

I like to point out toOpenCA[1], a project with the aim to manage such an PKI.

[1] http://openca.sourceforge.net/

polarizers 2cent +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + +
+ + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (206.66.xx.xx) on Thu 10 Nov 2005 at 18:34
+
+ +
+ Good article indeed. A commandline alternative to OpenCA is called easy-rsa, which ships with Openvpn[1]. This series of scripts lets you easily create and manage one or more CAs.

[1] http://www.openvpn.net +

+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + +
+ + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (198.134.xx.xx) on Thu 10 Nov 2005 at 16:26
+
+ +
+
I would point out the difference between a self-signed certificate (in which there is NOT a certificate authority) and self-signing your certificates using a private certificate authority. The distinction is an important one but too often overlooked when people talk/write about certificates.

Self-signed certificates DO NOT scale. Self-signing scales reasonably well, if you take measures to distribute your CA public key.
+
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + +
+ + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (66.43.xx.xx) on Mon 12 Jun 2006 at 14:04
+
+ +
+
I was wondering what size installations people have been able to administer using this technique (or a similar one). I'm trying to convince the management that being our own CA is a good idea and that we can make this scale to our purposes (less than 1000 users, half of which are our clients, not employees). Any use cases or scenarios would be very helpful.

Thanks,
Andrew
+
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + +
+ + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (61.9.xx.xx) on Fri 18 Nov 2005 at 04:40
+
+ +
+
hi,

Thank you for your article, without it, I would never have had a hope of getting as far as I did.

I had already tried to issue certs before, but they were not working properly - they were under '/etc/ssl/certs' and ' /etc/ssl/private' - following your tutoria, the new ones were generated under '/etc/ssl/CA' and '/etc/ssl/CA/private'..

Q1: Can I simply copy the/your new certs over the old ones?


Q2: I am not sure where the Apache2 refereces are to the certs - can you tell me?

Apache

File Comment
/home/httpd/html Apache DocumentRoot
/home/httpd/ssl SSL-related files
/home/httpd/ssl/cert.pem Site certificate
/home/httpd/ssl/key.pem Site private key

........................
Never-the-less - thank you very much.

Danny Regan
+
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by dregan (61.9.xx.xx) on Fri 18 Nov 2005 at 05:14
+[ Send Message ]
+ +
+
hi,

Thank you for your article, without it, I would never have had a hope of getting as far as I did.

I had already tried to issue certs before, but they were not working properly - they were under '/etc/ssl/certs' and ' /etc/ssl/private' - following your tutoria, the new ones were generated under '/etc/ssl/CA' and '/etc/ssl/CA/private'..

Q1: Can I simply copy the/your new certs over the old ones?


Q2: I am not sure where the Apache2 refereces are to the certs - can you tell me?

Apache

File Comment
/home/httpd/html Apache DocumentRoot
/home/httpd/ssl SSL-related files
/home/httpd/ssl/cert.pem Site certificate
/home/httpd/ssl/key.pem Site private key

........................
Never-the-less - thank you very much.

Danny Regan
+
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by dregan (61.9.xx.xx) on Fri 18 Nov 2005 at 05:19
+[ Send Message ]
+ +
+
Thank you for your article.

I apt-get install stunnel with out problems but when I run the command;

stunnel -p /etc/ssl/certs/key-cert.pem

I get;
ns1:/etc/ssl/certs# stunnel -p /etc/ssl/certs/key-cert.pem
2005.11.18 16:17:30 LOG3[9812:16384]: Either -r, -l (or -L) option must be used

Try 'stunnel -h' for more information.

ns1:/etc/ssl/certs#
.................
stunnel -V shows the following

Compile time defaults:
-v level no verify
-a directory /etc/ssl/certs
-A file (none)
-S sources 3
-t timeout 300 seconds
-B bytes 64
-D level 5
-P pid dir /var/run/stunnel/
-p pemfile in server mode: /etc/ssl/certs/stunnel.pem
in client mode: none

Any Suggestions (please)?



+
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by krischeu (195.30.xx.xx) on Wed 30 Nov 2005 at 10:46
+[ Send Message ]
+ +
+
Very userful Howto,

first i run in some problems within using a fresh debian sarge 3.1 install.
I was googling around, but thousands of people got the same error, but nowhere is a solution. I found little solutions - everywhere a little piece.

Errormessage is everytime:
-------------------------
can't find openssl.cnf
unable to find 'distinguished_name' in config
Unable to load config info
unable to load CA private key sign

This solve my problems by creating and signing the certificates:
----------------------------------------------------------------

edit the /root/.bashrc
PATH=/usr/lib/ssl/misc:/etc/ssl:$PATH
export PATH
OPENSSL_CONF=/etc/ssl/openssl.cnf
export OPENSSL_CONF
SSLEAY_CONF=/etc/ssl/openssl.cnf
export SSLEAY_CONF

Do a link
cd /usr/lib/ssl/misc
ln -s /etc/ssl/openssl.cnf openssl.cnf

Copy the /etc/ssl/openssl.cnf to openssl.cnf and change the original against the one of the howto.

Edit it to your environment.

Rest is like the howto says.

Best regards,

heinz.krischeu@easi.de
+
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (213.225.xx.xx) on Wed 9 May 2007 at 15:56
+
+ +
+ Great article!

Thanks a lot for writing it.

-o +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (213.162.xx.xx) on Tue 31 Jul 2007 at 14:24
+
+ +
+ Very useful article... but there is one small problem.

It doesn't work.

Using the openssl.cnf as supplied in the article and copying the commands exactly I get the error message:

error, no objects specified in config file
problems making Certificate Request

and cacert.pem is not generated.

Googling the error message doesn't provide any useful results. And it's not a very helpful error message to someone who knows sod all about how this works which is why I am reading the article in the first place.

This is using openssl 0.9.8c-4 in Debian.

Any idea what's going on?
+
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + +
+ + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (75.18.xx.xx) on Tue 11 Dec 2007 at 05:06
+
+ +
+ "Using the openssl.cnf as supplied in the article and copying the commands exactly I get the error message:

error, no objects specified in config file
problems making Certificate Request"

It sounds like you edited /etc/ssl/openssl.cnf instead of making a new openssl.cnf in the current directory.

If you copied the commands exactly, then the mentioned command line parameter -config ./openssl.cnf is drastically different from -config /etc/openssl/openssl.cnf

Hope this helps.


Great HOWTO! It's always nice to have the methods and underlying framework explained rather than just being given commands/parameters and being expected to copy/paste them blindly. +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + +
+ + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (200.123.xx.xx) on Tue 9 Oct 2007 at 15:01
+
+ +
+ Thanks for this article. It has help me to configure mi box without SSL warnings.

But, I've a question. How can I use the cacert.pem with Outlook? When I try to import it, Outlook complains. It seems that expect another format. Do I have to convert it? How?
Thanks! +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by olberger (157.159.xx.xx) on Thu 15 May 2008 at 12:49
+[ Send Message ]
+ +
+ The article mentions :
Note: a self-signed cert can be created with the simple command mod-ssl-makecert, part of the Debian package libapache-mod-ssl.

FYI, there's a 'ssl-cert' package which contains the 'make-ssl-cert' command which can be used to do so.

Hope this helps, +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (88.73.xx.xx) on Thu 9 Oct 2008 at 18:32
+
+ +
+ Good article! This one is easy to understand, if u got some solid *nix knowledge. Anyway maybe in the near future we can build secure websites for ourselfs :) THX +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by mtmonacelli (74.95.xx.xx) on Fri 26 Dec 2008 at 20:29
+[ Send Message ]
+ +
+ I've avoided SSL for lack of understanding...till now. Finally a well written step by step, easy to follow tutorial on how to use SSL! Thank you for helping break down the barrier to entry. +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (190.169.xx.xx) on Tue 3 Mar 2009 at 21:25
+
+ +
+ I can't find libapache-mod-ssl in Lenny, what command can I use now? +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + +
+ + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (194.63.xx.xx) on Fri 20 Mar 2009 at 14:28
+
+ +
+

Hy,

i have the command available on a debian lenny. There is also the package ssl-cert installed!

i think the package containing "make-ssl-cert" is "ssl-cert". Try to install that package with aptitude or apt.

hope that helps +

+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + +
+ + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (190.169.xx.xx) on Thu 5 Nov 2009 at 15:19
+
+ +
+ In:

$ openssl ca -out cert.pem -config ./openssl.cnf -infiles req.pem

it is created for one year. You need to add -days if you want it to last for longer, say ten years:

$ openssl ca -out cert.pem -days 3650 -config ./openssl.cnf -infiles req.pem +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + +
+ + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (24.69.xx.xx) on Thu 5 Nov 2009 at 17:47
+
+ +
+ Of course, your certificate is only valid while your root certificate remains unexpired. In the example, the root certificate is created with a ten-year life-span, so there is no point in specifying "-days" for a period longer than the root certificate's remaining life. +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + +
+ + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (82.243.xx.xx) on Thu 12 Nov 2009 at 03:41
+
+ +
+ Hi,

thanks for this howto.

I have a problem when I start the line openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 3650 -config ./openssl.cnf
it gives me this error :
Error loading extension section V3_ca

Do you know what append?

Thanks +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by nlindley (12.94.xx.xx) on Thu 18 Feb 2010 at 22:24
+[ Send Message ]
+ +
+ Some Mac applications use WebDAV, e.g. iCal, and require a basicConstraint of "critical" in the v3_ca section to use SSL. Here's how that section looks in my configuration:

[ v3_ca ]
basicConstraints = critical,CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (193.110.xx.xx) on Tue 27 Apr 2010 at 08:35
+
+ +
+ The one piece of information I'd like to see still is how to distribute certificates in a Debian package. I would have thought there would be a written policy for this (this is Debian we are talking about after all :-) but so far, I have come up with nothing. It seems that openssl and ca-certificates put stuff in /etc/ssl and more specifically /etc/ssl/certs but is that sufficient for e.g. Firefox and Thunderbird to find the certificates, or is there something more I need to do? +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Certificate Generator + +
+ +
+ Posted by Anonymous (83.227.xx.xx) on Wed 19 May 2010 at 08:34
+
+ +
+ If you do development stuff that doesn't require too much security, you might want to try this online self-signed certificate generator. +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (213.177.xx.xx) on Thu 14 Oct 2010 at 16:23
+
+ +
+ The default hash algorithm is now insecure. I've had to redo all my certificates after I started to test SSL with cadaver, which reported "Certificate verification error: signed using insecure algorithm". Hence please change:

default_md = md5

to

default_md = sha1

in openssl.cnf. Might help troubleshoot weird errors. +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (75.148.xx.xx) on Tue 21 Jun 2011 at 18:24
+
+ +
+ 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\, where 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 +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (184.154.xx.xx) on Thu 30 Jun 2011 at 13:08
+
+ +
+ Good article though I recommend not to use self signed SSL certificates as they may harm your online business reputation.Its better to get one from trusted SSL reseller. SSL Certificate +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by richjoslin (173.151.xx.xx) on Thu 12 Jan 2012 at 23:39
+[ Send Message ]
+ +
+ Maybe I overlooked it, and maybe this was just my experience, but I used different org names and got an error.

If I create a CA cert with one org name and then create a CSR with different org name, I get this at the end of the output when I try to sign the certificate:

"The organizationName field needed to be the same in the CA certificate (Org A) and the request (Org B)"

And it isn't perfectly clear that it was an error, but there is no cert in newcerts, so that's my clue that it didn't work. My solution was to recreate the CSR with a matching org name.

I think it would be better if I could use different org names for different certs. Or does that defeat the "self-signing" terminology? +
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + + + +
+
+ + + # + + +
+ +
Re: Creating and Using a self signed SSL Certificates in debian + +
+ +
+ Posted by Anonymous (63.194.xx.xx) on Thu 20 Sep 2012 at 15:53
+
+ +
+ In Debian Lenny, the only real "gotcha" that slowed me up (with a really weird browser Error code: ssl_error_rx_record_too_long) was having to add the default-ssl (where SSLCertificateFile, SSLCertificateKeyFile and SSLCertificateChainFile are updated with the cerificate locations)

from
/etc/apache2/sites-available/default-ssl
to
/etc/apache2/sites-enabled/

The self signed SSL Certificates work but, since the constant browser warnings are a hassle, I decided to use a "cheap" (~$12/year) goDaddy.com SSL Certificate.

Thanks for the article!
+
+ +

+ [ + + Parent + + + + + + | Reply to this comment + + + + + + + + + + + + +] +

+ +
+ + + + +

+ + + + + + +
+
+
+
+
+ + + + + +

Sign In

+
+ + +

Username:

+

Password:

+

+

[Register|Advanced]

+ + + +
+ + + + + + + + + + + + + + + + + + + + + +

 

+
+

Flattr

+
+
+ + + +

 

+
+

Current Poll

+ +
+

Which init system are you using in Debian?

+ +
+ +
+ +
+ +
+ +
+ + ( 1143 votes ~ 7 comments )

+
+ +
+ + + +

 

+ + + + + +

 

+ + + + + + + + + + + + + + + + + + + + + +
+
+
+
+ + +