Professional Documents
Culture Documents
How To Create SSL X509 Certificate
How To Create SSL X509 Certificate
How To Create SSL X509 Certificate
http://www.imacat.idv.tw/tech/sslcerts.html
:::
Travellers Guestbook | Keep Travelling | Tavern Lobby | Write to ME!!! | Search: | | English
:::
Query
TABLE OF CONTENTS
1 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
8. 9.
4. Outlook Express 4/5 5. Eudora 5.1 or Newer 6. Becky! 7. Opera Mail Configure Programs That Do Not Support SSL/TLS 1. Stunnel Review and Discussion 1. Introduction to SSL/X.509 2. Warning: Invalid Certificate 3. Wait! What Data? 4. So, Im Safe Now (with SSL)? 5. What Is a Digital Signature? 6. What Is a Certificate? 7. What Is a CA? 8. What Is a Root CA? 9. How to Fill in the Certificate Request? 10. Review to the X.509 Certificate System 11. Alternative Methods to Create SSL/X.509 Certificates Annotations References Notes
PREFIX
Copyright 2002-2006 imacat. All rights reserved. Please read the Copyright License first, if you want to forward or cite parts or all of this article. Our goal is: To create X.509 SSL certificates by our name, with OpenSSL and under Linux/*BSD/UNIX. We will create 2 certificates: First we will create a root CA, which is by our name (XXX Association, YYY Corporation) and issued by itself. Then we will create a certificate, which is by the server name (www.abccompany.com) and issued by our root CA created in the first step. To simplify this process, we will not be creating any intermediate CA, and will issue certificates with our root CA directly. This article merely tells you how to create SSL X.509 certificates. It does not cover the system security. It does not cover the encryption/decryption algorithms. It does not cover how to install OpenSSL as well. You are assumed to be understanding the basic concept of public key/private key cryptography, knowing what is the RSA/DSA algorithms. You are also assumed to have a properly-installed OpenSSL, that is configured according [1] to FHS , as:
./config --prefix=/usr --openssldir=/usr/share/ssl
or use a RPM or DEB package. This article is a HOWTO. For this reason, the step-by-step tutorial instruction (how) are organized in the front. The explanation and discussion (what and why) are left behind. If you have difficulty understanding the tutorial instruction, or wish to learn more about SSL/X.509 first, you can go directly to the rear part. There is no necessity to read from the beginning.
2 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
CAUTION: YOUR CERTIFICATES CREATED ACCORDING TO THE INSTRUCTION HERE WILL STILL PRODUCE A WARNING: INVALID CERTIFICATE. Refer to Introduction to SSL/X.509 and Warning: Invalid Certificate for more details. According to X.509, you can create certificates with either RSA or DSA key pairs. But only RSA key pairs are capable of exchanging keys when starting a new SSL connection with a SSL server. You can only use RSA key pairs as your server certificates. On the other hand, CAs do not have to exchange keys. They only issue other certificates. You can use either RSA or DSA key pair as your CAs. But, since some SSL programs do not support the DSA algorithm yet , well still create RSA CAs here for the compatibility reason. You can create your root CA as an unprivileged user. Theres no need to be root to do this. But if your root CA will be used to issue certificates for your whole organization, you are strongly suggested to create it with the root privilege for security reasons. Again, you can also create your server certificate as an unprivileged user. Theres no need to be root to do this. But if your server certificate will be used by this server, you are strongly suggested to created it with the root privilege for security reasons.
[2]
IF YOU ARE ROOT, AND ARE CREATING A ROOT CA FOR YOUR WHOLE ORGANIZATION
Set up Your OpenSSL Environment
If you install your OpenSSL with the instruction above:
./config --prefix=/usr --openssldir=/usr/share/ssl
or use Red Hats RPM package, your OpenSSL configuration will be located at /usr/share/ssl. If you use Mandrakes RPM package, your OpenSSL configuration will be located at /usr/lib/ssl. Both of them violate FHS requirement. They are not convienent for backup, too. The OpenSSL configuration should be located at /etc/ssl. If you use Debians apt, your OpenSSL will be just there at /etc/ssl.
# Set mkdir mkdir chmod mkdir mkdir mkdir up the relevant directories -p /etc/ssl -p /etc/ssl/private og-rwx /etc/ssl/private -p /etc/ssl/certs -p /etc/ssl/crl -p /etc/ssl/newcerts
# Set up your OpenSSL configuration file[3] mv /usr/share/ssl/openssl.cnf /etc/ssl ln -s /etc/ssl/openssl.cnf /usr/share/ssl/openssl.cnf # Set up the location of your OpenSSL configuration file[4] export OPENSSL_CONF="/etc/ssl/openssl.cnf" # Add the location of your OpenSSL configuration file to your .bashrc[5] echo "# Location of the OpenSSL configuration file" >> ~/.bashrc echo "export OPENSSL_CONF=\"/etc/ssl/openssl.cnf\"" >> ~/.bashrc
3 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
to
dir = /etc/ssl # Where everything is kept
2. Fill in the Certificate Request A certificate request is a combination of your private key and your self-infomation in reality, in order for the CA to verify its correctness and sign on it later. For this reason, you will be asked several questions relevant to this key, including your country, city, organization, department, the certificate name, contact e-mail, and your applying valid period. Fill in them one by one. Refer to What Is a Certificate? for more details. If you want to use your root CA as the same server certificate for your server, fill in your servers full qualified domain name (FQDN, i.e. www.abc.com) as the certificates common name here. Refer to Alternative Methods to Create SSL/X.509 Certificates for more details. If you dont know how to fill in the certificate request, refer to How to Fill in the Certificate Request? for more details.
# Fill in the certificate request openssl req -new -key /etc/ssl/private/myrootca.key -out /tmp/myrootca.req
3. Issue the Certificate Root CA is the topmost CA. No further higher CA can issue a root CA. It has to be signed by itself. Refer to What is a Root CA? for more details.
4 of 28 04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
Root CA should never expire. Otherwise, all the certificates it had issued will need to be reissued, and all of the relevant SSL programs will need to be reconfigure. So we set its valid period to 7305 days (20 years). If we do not set the valid period, it will be set to its default as 30 days (1 month). The certificate request is not required after it is signed. We can safely delete it.
# Sign its own certificate request openssl x509 -req -days 7305 -sha1 \ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \ -signkey /etc/ssl/private/myrootca.key \ -in /tmp/myrootca.req -out /etc/ssl/certs/myrootca.crt # Delete the certificate request rm -f /tmp/myrootca.req
Thats all. The private key is /etc/ssl/private/myrootca.key, and the self-signed public key certificate is /etc/ssl/certs/myrootca.crt. myrootca.key is your private key. You should protect it carefully. It should be only readable by root, and its permission should be 0400. myrootca.crt is your public key certificate. You should spread it out and make it free for everyone. You should put it in your intranet or on your web site for everyone to download and install it freely by themselves.
2. Fill in the Certificate Request A certificate request is a combination of your private key and your self-infomation in reality, in order for the CA to verify its correctness and sign on it later. For this reason, you will be asked several questions relevant to this
5 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
key, including your country, city, organization, department, the certificate name, contact e-mail, and your applying valid period. Fill in your servers full qualified domain name (FQDN, i.e. www.abc.com) as the certificates common name here. Refer to What Is a Certificate? for more details. If you dont know how to fill in the certificate request, refer to How to Fill in the Certificate Request? for more details.
# Fill in the certificate request openssl req -new -key /etc/ssl/private/myhost.key -out /tmp/myhost.req
3. Issue the Certificate with the Root CA[8] The valid period of the server certificate is not important at all. Just issue a new one when it is expired. SSL programs know only the root CAs but not the server certificates. A server certificate is valid as soon as it is issued by a valid root CA. You dont have to reconfigure the SSL programs. But, to avoid the trouble to reissue certificates, we will set its valid period to 3650 days (about 10 years.) The certificate request is not required after it is signed. We can safely delete it.
# Sign the certificate request openssl x509 -req -days 3650 -sha1 \ -extfile /etc/ssl/openssl.cnf -extensions v3_req \ -CA /etc/ssl/certs/myrootca.crt -CAkey /etc/ssl/private/myrootca.key \ -CAserial /etc/ssl/myrootca.srl -CAcreateserial \ -in /tmp/myhost.req -out /etc/ssl/certs/myhost.crt # Delete the certificate request rm -f /tmp/myhost.req
Thats all. The private key is /etc/ssl/private/myhost.key. You should protect it carefully. It should be only readable by root, and its permission should be 0400. The public key certificate is /etc/ssl/certs/myrootca.crt. You should spread it out and make it free for everyone. This private/public key pair can be used in HTTPS, POP3/TLS, SMTPS/TLS and other SSL services. They should not be moved to other places. You should not put your private key here and there to reduce security risks. You can set the location of the certificates to here in your service configuration files.
[9]
6 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
# Set up the location of your OpenSSL configuration file[11] export OPENSSL_CONF="$HOME/etc/ssl/openssl.cnf" # Add the location of your OpenSSL configuration file to your .bashrc[12] echo "# Location of the OpenSSL configuration file" >> ~/.bashrc echo "export OPENSSL_CONF=\"$HOME/etc/ssl/openssl.cnf\"" >> ~/.bashrc # Create the random file[13] openssl rand -out ~/etc/ssl/private/.rand 1024 chmod og-rwx ~/etc/ssl/private/.rand
to
dir = ~/etc/ssl # Where everything is kept
Create a Root CA
If you have created your root CA before, dont do this step again. Otherwise, all your issued certificates will become invalid and youll have to sign them again. Unless your root CA itself expires, is lost, or its private key leaks out, you should never recreate your root CA for any reason. Assuming your root CA is called myrootca. 1. Generate a Private Key (and a Public Key) We will create a new private key here. The public key can be derived from its corresponding private key. Please set a proper password for the private key of your root CA.
# Create an RSA[14] private key openssl genrsa -des3 -out ~/etc/ssl/private/myrootca.key 2048 chmod og-rwx ~/etc/ssl/private/myrootca.key
2. Fill in the Certificate Request A certificate request is a combination of your private key and your self-infomation in reality, in order for the CA to verify its correctness and sign on it later. For this reason, you will be asked several questions relevant to this key, including your country, city, organization, department, the certificate name, contact e-mail, and your applying valid period. Fill in them one by one. Refer to What Is a Certificate? for more details. If you want to use your root CA as the same server certificate for your server, fill in your servers full qualified domain name (FQDN, i.e. www.abc.com) as the certificates common name here. Refer to Alternative Methods to Create SSL/X.509 Certificates for more details. If you dont know how to fill in the certificate request, refer to How to Fill in the Certificate Request? for more details.
7 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
# Fill in the certificate request openssl req -new -key ~/etc/ssl/private/myrootca.key -out ~/tmp/myrootca.req
3. Issue the Certificate Root CA is the topmost CA. No further higher CA can issue a root CA. It has to be signed by itself. Refer to What is a Root CA? for more details. Root CA should never expire. Otherwise, all the certificates it had issued will need to be reissued, and all of the relevant SSL programs will need to be reconfigure. So we set its valid period to 7305 days (20 years). If we do not set the valid period, it will be set to its default as 30 days (1 month). The certificate request is not required after it is signed. We can safely delete it.
# Sign its own certificate request openssl x509 -req -days 7305 -sha1 \ -extfile ~/etc/ssl/openssl.cnf -extensions v3_ca \ -signkey ~/etc/ssl/private/myrootca.key \ -in ~/tmp/myrootca.req -out ~/etc/ssl/certs/myrootca.crt # Delete the certificate request rm -f ~/tmp/myrootca.req
Thats all. The private key is ~/etc/ssl/private/myrootca.key, and the self-signed public key certificate is ~/etc/ssl/certs/myrootca.crt. myrootca.key is your private key. You should protect it carefully. It should be only readable by yourself, and its permission should be 0400. myrootca.crt is your public key certificate. You should spread it out and make it free for everyone. You should put it on your web site for everyone to download and install it freely by themselves.
8 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
2. Fill in the Certificate Request A certificate request is a combination of your private key and your self-infomation in reality, in order for the CA to verify its correctness and sign on it later. For this reason, you will be asked several questions relevant to this key, including your country, city, organization, department, the certificate name, contact e-mail, and your applying valid period. Fill in your servers full qualified domain name (FQDN, i.e. www.abc.com) as the certificates common name here. Refer to What Is a Certificate? for more details. If you dont know how to fill in the certificate request, refer to How to Fill in the Certificate Request? for more details.
# Fill in the certificate request openssl req -new -key ~/etc/ssl/private/myhost.key -out /tmp/myhost.req
3. Issue the Certificate with the Root CA[8][15] The valid period of the server certificate is not important at all. Just issue a new one when it is expired. SSL programs know only the root CAs but not the server certificates. A server certificate is valid as soon as it is issued by a valid root CA. You dont have to reconfigure the SSL programs. But, to avoid the trouble to reissue certificates, we will set its valid period to 3650 days (about 10 years.) The certificate request is not required after it is signed. We can safely delete it.
# Sign the certificate request openssl x509 -req -days 3650 -sha1 \ -extfile ~/etc/ssl/openssl.cnf -extensions v3_req \ -CA ~/etc/ssl/certs/myrootca.crt -CAkey ~/etc/ssl/private/myrootca.key \ -CAserial ~/etc/ssl/myrootca.srl -CAcreateserial \ -in /tmp/myhost.req -out ~/etc/ssl/certs/myhost.crt # Delete the certificate request rm -f /tmp/myhost.req
Thats all.[16] The private key is ~/etc/ssl/private/myhost.key. You should protect it carefully. It should be only readable by root, and its permission should be 0400. The public key certificate is ~/etc/ssl/certs /myrootca.crt. You should spread it out and make it free for everyone. This private/public key pair can be used in HTTPS, POP3/TLS, SMTPS/TLS and other SSL services. They should not be moved to other places. You should not put your private key here and there to reduce security risks. You can set the location of the certificates to here in your service configuration files.
Linux/*BSD/UNIX
9 of 28 04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
MS-WINDOWS
MS-WINDOWS has a common system certificate database. Go to the [Control Panel]. Theres a [Internet Options] inside. Double click on it. A window titled [Internet Content] will pop up. Click on the [Content] tab at the top to move to the [Content] page. Theres a section titled [Certificates] in the middle, with a button [(C)ertificates...] inside. Click on that button. Another window titled [Certificates] will pop up. This is the place where MS-WINDOWS stores and manages its system certificate database
.[20]
To add our root CA in, copy our root CA myrootca.crt to our WINDOWS and double click on it. A window titled [Certificates] will pop up, displaying the content of our root CA. Click the [Install Certificate] button below. A [Certificate Manager Import Wizard] will pop up. Click the [Next] button step by step. Thats all. To the extend of my knowledge, the WINDOWS programs that will ultilize this common system certificate database include: Internet Exporer, Outlook Express, Outlook and Symantec pcAnywhere. As long as our root CA is there, it will be available to all these programs.
HTTP
HTTP is the first SSL protocol. In fact, SSL was designed for HTTP by Netscape, in order to make secure transaction on the web. To run SSL, Netscape allocated a new TCP port 443 dedicated for SSL and named it as
10 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
HTTPS. Since that, SSL on HTTP is doing the old SSL way. You have to use the HTTPS(443) port. No TLS negotiation is available. Apache Apache can run HTTPS with either Apache-SSL or mod_ssl. Please refer to their individual manual. CAUTION: APACHE CAN ONLY HAVE ONE CERTIFICATE IN ITS MEMORY. Since the server name (site name) is recorded on the certificate, one Apache process can only run SSL with one site name. The result is that, one Apache process can only run one SSL site. If you want to run several SSL sites, you have to run many Apache processes, each on a different IP or a different TCP port. Taking mod_ssl as an example. Set up your you have successfully installed mod_ssl:
httpd.conf
as follows after
## mod_ssl.c: mod_ssl configuration <IfModule mod_ssl.c> Listen 443 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl SSLSessionCache dbm:/var/log/apache/ssl_scache SSLSessionCacheTimeout 300 SSLPassPhraseDialog builtin SSLMutex file:/var/log/apache/ssl_mutex SSLRandomSeed startup builtin SSLRandomSeed connect builtin SSLLog /var/log/apache/ssl_engine_log SSLLogLevel info SSLCipherSuite ALL:!ADH:!EXP56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/ssl/certs/myhost.crt SSLCertificateKeyFile /etc/ssl/private/myhost.key <VirtualHost *:443> SSLEngine on </VirtualHost> </IfModule>
httpd
POP3
POP3 has both ways: The traditional SSL on a dedicated POP3(995) port, and the newer TLS with a STARTTLS extension on the same POP3(110) port. The STARTTLS command for POP3 is STLS. Qpopper
11 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
Refer to the Qpopper manual on how to compile and install the Qpopper. Qpopper is capable of both POP3(995) and POP3(110)/TLS. However, it can only run on one port with one SSL method. If you need both POP3(995) and POP3(110)/TLS, you have to run 2 seperated qpopper processes, each with a different configuration file. Set up your /etc/qpopper.conf as follows:
# qpopper.conf: Configuration file for Qpopper POP3(110)/TLS set clear-text-password = always set statistics = true set tls-support = stls set tls-private-key-file = /etc/ssl/private/myhost.key set tls-server-cert-file = /etc/ssl/certs/myhost.crt
Youll see 2 popper processes running simultaneously, each with a different set of arguments. Try:
netstat -ap | grep popper
popper
SMTP
SMTP has both ways, too: The old, traditional SMTPS(465) port dedicated for SSL, and the nowadays TLS over the same SMTP(25) port with a STARTTLS extension. TLS is strongly recommended here. It uses the same TCP port and thus has a better compatibility when sending and receiving mails. Use TLS as long as possible.[17] The STARTTLS command for SMTP is STARTTLS. Sendmail Sendmail can compile in both SMTPS and TLS supports. But SMTPS support is not official for Sendmail yet, and is categorized as FFR (for future release) currently. You wont find any infomation for SMTPS support in the
12 of 28 04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
whole Sendmail documentation. Only TLS support is documented at this time. When delivering mails, Sendmail will only try STARTTLS on the SMTP(25) port. If the other side does not understand TLS, it will continue to send mails unencrypted. No further SSL attempt will be made to the SMTPS(465) port of the other side. To reduce the delivery difficulties as much as possible, Sendmail wont verify the certificate of the other side at all. Encryption is used as long as possible. After all, it is really meaningless to verify certificates in TLS.
/site.config.m4
To enable Sendmails SSL support, add the follows to before you compile your Sendmail:
devtools/Site
# STARTTLS - SSL/TLS support APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS') APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto') # SMTP SSL - SMTPS support APPENDDEF(`conf_sendmail_ENVDEF', `-D_FFR_SMTP_SSL')
Next we set up the Sendmail configuration file /etc/mail/sendmail.cf. If you build your Sendmail configuration file with m4, add the follows to your m4 file config.mc:
dnl Sendmail SMTPS/STARTTLS SSL Support define(`confCACERT_PATH', `/etc/ssl/certs') define(`confCACERT', `/etc/ssl/certs/myrootca.crt') define(`confSERVER_CERT', `/etc/ssl/certs/myhost.crt') define(`confSERVER_KEY', `/etc/ssl/private/myhost.key') define(`confCLIENT_CERT', `/etc/ssl/certs/myhost.crt') define(`confCLIENT_KEY', `/etc/ssl/private/myhost.key') DAEMON_OPTIONS(`Name=MTA')dnl DAEMON_OPTIONS(`Port=465, Name=MTASSL, M=s')dnl
sendmail
TCP ports.
But this is not the end of the story. Since version 8.12.1, Sendmail has seperated its server and its client, in order to improve its security. The Sendmail server needs to bind to the low port SMTP(25) that belows 1024, and to save mails into everyones mail
13 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
boxes. It still requires the root priviledge to do so. But this can simply be archived by starting Sendmail server as root. The Sendmail client does not need the root priviledge. It only needs the priviledge to write into a dedicated mail spool. So, Sendmail has changed from setuid root to setgid smmsp[19]. When a Sendmail client needs to deliver mails, it connects to a SMTP server with to do so. The Sendmail server can read the certificate private key without any problem, as it has the root privilege. But the Sendmail client dont. It cannot read our server private key now. What can we do? We dont want our Sendmail to be setuid-root. We dont want to permit others to read the private key of our server certificate, either. We have to create another certificate that is only readable by the smmsp group, dedicated for our Sendmail client only:
# Set mkdir chgrp chmod mkdir up the relevant directories -p /etc/mail/private smmsp /etc/mail/private o-rwx /etc/mail/private -p /etc/mail/certs
# Create an RSA private key openssl genrsa -out /etc/mail/private/myhost-msp.key 2048 chgrp smmsp /etc/mail/private/myhost-msp.key chmod o-rwx /etc/mail/private/myhost-msp.key # Fill in the certificate request openssl req -new -key /etc/mail/private/myhost-msp.key \ -out /tmp/myhost-msp.req # Sign the certificate request openssl x509 -req -days 3650 -sha1 \ -extfile /etc/ssl/openssl.cnf -extensions v3_req \ -CA /etc/ssl/certs/myrootca.crt -CAkey /etc/ssl/private/myrootca.key \ -CAserial /etc/ssl/myrootca.srl -CAcreateserial \ -in /tmp/myhost-msp.req -out /etc/mail/certs/myhost-msp.crt # Delete the certificate request rm -f /tmp/myhost-msp.req
Thats all. You dont have to restart the Sendmail, as we are not configuring the Sendmail server here. ^_*' You can send a mail to yourself, and watch the maillog to see if SSL succeeds.
14 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
Sep 14 04:19:24 rinse sendmail[12093]: STARTTLS=client, relay=localhost.localdom ain., version=TLSv1/SSLv3, VERIFY=OK, cipher=EDH-RSA-DES-CBC3-SHA, bits=168/168
Internet Explorer
Internet Explorer ultilizes WINDOWSs common system certificate database. Our root CA is available as long as it is imported into this certificate database. Refer to Configure MS-WINDOWS for more details.
Opera
Until the time this article is written, Opera (6.05) does not support DSA algorithm. Only RSA algorithm is supported. You can only import RSA CAs, but not DSA CAs. Opera. Starting from the tool bar, from [File], a window titled [Preferences] will pop up. Click on the [Security] at the bottom of the left side menu. There will be a [Authorities...] button at the upper right. Click on the button. A window titled [Certificate Authorities] will pop up. Click on the [Import...] button at the upper right, find out our root CA and double click to import it. Thats all. Start your
[Preferences...],
Lynx
Until the time this article is written, Lynx (2.8.4) does not verify SSL
15 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
Netscape 4 or Earlier
Netscape 4 or earlier does not support SSL.
http://www.imacat.idv.tw/tech/sslcerts.html
SMTP:]
Outlook Express ultilizes WINDOWSs common system certificate database. Our root CA is available as long as it is imported into this certificate database. Refer to Configure MS-WINDOWS for more details.
[24]
When receiving mails, Eudora tries STARTTLS to negotiate with the mail server first. If it succeeds, both sides will enter SSL and Eudora will start to receive mails. Otherwise, it will still start to receive mails without SSL encryption as usual. You dont have to configure SSL specifically. But theres a big problem in Eudoras STARTTLS approach. If, after STARTTLS succeeds and both sides enter SSL, Eudora fails to verify the mail servers certificate, it will stop receiving mails and close the connection immediately. It will not try to connect again without SSL, nor will it ask the user for the action to take. Only a small warning will be displayed at the bottom of Eudora in that case. If you add STARTTLS support to your mail server just now with a self-issued server certificate, your users previously-working Eudora will stop working without asking the user. Your innocent Eudora users may panic. Thats another big
17 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
problem with Eudoras SSL design. After all, it is really meaningless to verify certificates in TLS. Also, Eudora should ask the user, but not close the connection immediately, since the reason of certificate verification failure is merely that the issuer of the certificate is not recognized by Eudora, but not that theres really any problem with the certificate itself. CAUTION: OpenSSLs default certificate file format is PEM, so we were all working on PEM certificate files previously. But Eudora can only read DER certificate files. PEM files are merely Base64-encoded DER files, to be compatible with the traditional 7-bit networks, so that they can be put onto the web sites, sent with e-mails or embedded into text files. We can convert PEM files to DER files with OpenSSL:
# Convert our root CA into DER files openssl x509 -in myrootca.crt -outform der -out myrootca-der.crt
To receive mails using SSL, start your Eudora. Starting from the tool bar, from [Tools], [Options...], a window titled [Options] will pop up. Click on [Checking Mail] from the [Category] left side menu. Fill your POP3 mail servers full qualified domain name (FQDN) in the [Mail Server:] at the right side. Choose [If available, STARTTLS] in [Secure Sockets when Receiving:] at the lower right. Then click [OK]. Thats all. from To send mails using SSL, start your Eudora. Starting from the tool bar, a window titled [Options] will pop up. Click on [Sending Mail] from the [Category] left side menu. Fill your SMTP mail servers full qualified domain name (FQDN) in the [Mail Server:] at the right side. Choose [If available, STARTTLS] in [Secure Sockets when Receiving:] at the lower right. Then click [OK]. Thats all.
[Tools], [Options...],
To add our CA in, you have to check your mails once first. There will be a error messages [SSL Negotiation Failed: Certificate Error: Cert Chain not trusted. ...] at the bottom of Eudora. Go to [Tools], [Options...], [Category], [Checking Mail], [Secure Sockets when Receiving:], as described above. Click on [Last SSL Info] below. A window titled [Eudora SSL Connection Infomation Manager] will pop up and display our certificate it just obtained from the server. Click on [Certificate Infomation Manager] at the bottom. Another window titled [Certificate Infomation Mangaer] will pop up. Now click on [Import Certificate] at the lower right, find out our root CAs DER file myrootca-der.crt and double click to import it. Thats all.
[25]
Becky!
Tomohiro Norimatsu, the author of Becky!, had said that due to SSL patent issues, Becky! will not have SSL support.[26] But we can still use a SSL wrapper to enable Becky! to send and receive mails through SSL connections. Refer to Configure Programs That Do Not Support SSL/TLS for more details.
Opera Mail
To receive mails using SSL, start your Opera. Starting from the tool bar, from [File], [Preferences...], a window titled [Preferences] will pop up. Click on [E-mail] from the [Category] left side menu. There will be a [Use Opera
18 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
menu at the right side. Choose the account you want to configure, and click the [Properties...] beside. A window titled [E-mail account properties...] will pop up. Click on the [Servers] tab at the top to move to the [Servers] page. In the [Incoming] section, fill your POP3 mail servers full qualified domain name (FQDN) in the [Server], and check the [TLS] beside the [Protocol] menu below. Then click [OK]. Thats all.
account]
To send mails using SSL, start your Opera. Starting from the tool bar, from [File], [Preferences...], a window titled [Preferences] will pop up. Click on [E-mail] from the [Category] left side menu. There will be a [Use Opera account] menu at the right side. Choose the account you want to configure, and click the [Properties...] beside. A window titled [E-mail account properties...] will pop up. Click on the [Servers] tab at the top to move to the [Servers] page. In the [Outgoing] section, fill your SMTP mail servers full qualified domain name (FQDN) in the [Server], and check the [TLS] beside the [Protocol] menu below. Then click [OK]. Thats all. Opera Mail ultilizes the certificate database of Opera. Our root CA is available as long as it is imported into this certificate database. Refer to Configure Opera for more details.
Stunnel
You can downnload Stunnel from its web site at http://www.stunnel.org/. Its a easy-to-use SSL wrapper that can be run under WINDOWS. To run Stunnel under WINDOWS, follow the simple instruction below: Download stunnel-x.xx.exe, libssl32.dll and libeay32.dll from the web site of Stunnel at http://www.stunnel.org/. Save your downloaded libssl32.dll and libeay32.dll into C:\WINDOWS \SYSTEM (for WINDOWS 98/ME) or C:\WINNT\SYSTEM32 (for WINDOWS NT/2000/XP). Create a new directory Stunnel under C:\Program Files, and save your downloaded stunnel-x.xx.exe here. Create a new file stunnel.conf under C:\Program Files\Stunnel, as the following example:
client = yes [pop3s] accept = localhost:50110 connect = my.mail.server:995
19 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
Run the C:\Program Files\Stunnel\stunnel-x.xx.exe. It will shrink to a small icon to the right of the tool bar at the bottom of your desktop. If you go to [MS-DOS Mode] or [Command Prompt] now and type:
netstat -an
Double click on the small Stunnel icon at the right of the tool bar will display the logs of Stunnel. Start your program. Modify your settings: Change your SMTP from my.mail.server port 25 to localhost port 50025. Change your POP3 from my.mail.server port 110 to localhost port 50110. Check your mails. Thats all. We have turn a non-SSL prorgam to send and receive data through SSL with Stunnel. This is only the basic of Stunnel. Stunnel itself is rather powerful. It can forward all kinds of protocols: POP3, SMTP, IMAP, NNTP, LDAP etc.. It can even reversely forward SSL connection to non-SSL services, so that clients can use SSL even the server itself does not support SSL. Please download the source package of Stunnel and refer to its manual inside. But theres a limitation to Stunnel: Stunnel does not support the TLS STARTTLS command. Stunnel works by building the SSL connection first and forward all the network traffic through that connection. It does not understand the specific protocol at all. Due to this limitation, it can only support the traditional full SSL.
20 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
sign themselves. SSL programs themselves recognize some reliable CAs in advance. When an SSL program encounters an SSL site, it may not recognize the received certificate from that site. But if it can recognize the signature on that certificate was signed by a recognized and truested CA, it can then know that this CA guaranteed that this certificate is OK. When an SSL program meets a valid certificate
But, on the contrary, if it cannot recognize the signature of that certificate, it cannot decide whether that certificate is OK or not. It will warn the user, then. When an SSL program meets a suspicious certificate
21 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
22 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
If you want to eliminate this warning, you have to teach the SSL program to recognize our CA first. After that, the SSL program will be able to recognize the CA signature on our certificate. It will not issue certificate invalidity warnings any more. Add our own CA in
23 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
Refer to discussions in Configure the Operating Systems, Configure the Browsers and Configure the E-mail Programs for how to do this. CAUTION: This practice requires you to manually add your CA into the SSL programs. For this reason, it is only practical for private servers, where you can add your CA into a limited number of SSL programs of nearby users, one by one. It is not possible if you are working on a public server. There is no way to add your CA into the SSL programs of numerous internet users around the world. This is due to the limitation of X.509. I can do nothing about it. If you do need SSL on your public server and care about this warning, please apply
24 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
for a certificate from one of the major CAs. It costs about USD 1,000 per year.
25 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
Youre always careful when you deal with an unfamiliar store in the real world. Its the same on the internet. You have to be careful making any transaction with any unfamiliar website, too. Think twice: Do I trust this company? Is this infomation important to me? For ex., for the guestbook messages, discussions, votes that are not so personal, you can send them freely. But for your real name, your cellular phone number, your home number, your credit card number, your e-mail address, etc., you should only give them to those that have your full trust.
What Is a Certificate?
A certificate is a public key, attached with its owners infomation (company name, server name, personal real name, contact e-mail, postal address, etc) and digital signatures. There will be one or more digital signatures attached on the certificate, indicating that these signers have verified that the owner infomation of this certificate is correct. In X.509, each valid certificate has exactly one signature from a CA. It means that this CA has verified the owner infomation on this certificate is correct. When an SSL program sees an unknown certificate, as long as that certificate has a valid CA signature on it, the program can be sure that this CA has verified the owner infomation on this certificate is correct.
What Is a CA?
CA is the abbreviation of Certificate Authority. CA is a part of the X.509 system. It is itself a certificate, too, attached with the owner infomation of this certificate authority. But its purpose is not to do encryption/decryption. Its purpose is to sign and issue certificates, in order to prove the owner
26 of 28
04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
infomation of that certificate is correct. Refer to the illustration in Introduction to SSL/X.509. Each valid CA has exactly one signature, too, from its governmental root CA. It means that this root CA has authorized this CA to issue certificates. When an SSL program sees an unknown certificate, whose signer CA is also unknwon, as long as that signer CA has a valid root CA signature on it, the program can be sure that this root CA has authorized this CA to issue certificates. The certificates issued by this CA will be valid, too.
1. You have to fill everything in English (ASCII characters). Only ASCII English characters are allowed in X.509 certificates.
27 of 28 04/08/2012 01:14 AM
http://www.imacat.idv.tw/tech/sslcerts.html
2. 3. 4. 5. 6. 7.
8. 9. 10.
is the two-letter upper-cased country code. The country code of Taiwan is TW. Refer to the ISO-3166 two-letter country code list if you are not in Taiwan. State Name is the full name of your country. You cannot fill in the country code above here. Fill in Taiwan here if you are in Taiwan. Locality Name is your place name. Fill in your city or your county here. Organization Name is the name of your organization. Fill in the name of your company name, your school or your institution here. Organizational Unit Name is the name of your department. Fill in the name of your department or your unit here. Organizational Unit Name is the name of this certificate. If this is a root CA, fill in the previous organization name here. You may append a RSA/2048 after the name to identify this CA in the future. If this is a server certificate, fill in the full qualified domain name of the server (www.abc.com) here. If this is an e-mail certificate, fill in your e-mail here. E-mail Address is the contact e-mail address of the applicant. Fill in your contact e-mail address here. A challenge password is the password for this certificate request. But we dont need a password for the request. Leave it blank. An optional company name is name of the certificate application agent. Leave it blank, too.
Country Name
| Tavern IMACATs and Womans Voice are twin sites. | | | This page conforms with XHTML 1.1 / CSS 2.1 / WCAG 1.0 Triple-A recommendations. Copyright 1998-2012 imacat. Please read the copyright before copying.
28 of 28
04/08/2012 01:14 AM