How to Create the SSL X.509 Certificates?
Table of Contents
- Prefix
- If You Are root
- If You Are an Unprivileged User
- Configure the Operating Systems
- Configure the Servers
- Configure the Browsers
- Configure the E-mail Programs
- Configure Programs That Do Not Support SSL/TLS
- Review and Discussion
- Introduction to SSL/X.509
- Warning: Invalid Certificate
- Wait! What Data?
- So, I’m Safe Now (with SSL)?
- What Is a Digital Signature?
- What Is a Certificate?
- What Is a CA?
- What Is a Root CA?
- How to Fill in the Certificate Request?
- Review to the X.509 Certificate System
- 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 to FHS[1], 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.
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[2], we’ll still create RSA CAs here for the compatibility reason.
You can create your root CA as an unprivileged user. There’s 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. There’s 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.
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 Hat’s RPM package, your OpenSSL configuration will be located at /usr/share/ssl. If you use Mandrake’s 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 Debian’s apt, your OpenSSL will be just there at /etc/ssl.
# Set up the relevant directories mkdir -p /etc/ssl mkdir -p /etc/ssl/private chmod og-rwx /etc/ssl/private mkdir -p /etc/ssl/certs mkdir -p /etc/ssl/crl mkdir -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 # Create the random file[6] openssl rand -out /etc/ssl/private/.rand 1024 chmod og-rwx /etc/ssl/private/.rand
Now modify your /etc/ssl/openssl.cnf. Change the line
dir = ./demoCA # Where everything is kept
to
dir = /etc/ssl # Where everything is kept
Create the Root CA
If you have created your root CA before, don’t do this step again. Otherwise, all your issued certificates will become invalid and you’ll 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[7] private key openssl genrsa -aes256 -out /etc/ssl/private/myrootca.key 4096 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 server’s full qualified domain name (FQDN, i.e. www.abc.com) as the certificate’s common name here. Refer to Alternative Methods to Create SSL/X.509 Certificates
for more details.
If you don’t 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.
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 -sha512 \ -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
That’s 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.
Create a Server Certificate
Assuming you are creating a server certificate for myhost.
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 log into the host that you are creating a server certificate for.
CAUTION: Do not set any password for the private key of your server certificate. Your SSL service will ask you for that password when it starts and reads its certificate private key. When your system boots and starts each server one by one, it will stop for the password from the keyboard for each SSL service that reads that private key. Now your server may be colocated at some IDC. You may leave the office during the weekend. You may not be able to attend to its keyboard at all times. You will not be happy to see if it cannot keep booting, waiting for a password from the keyboard, after a remote reboot or a crashed auto-reboot.
# Create an RSA private key openssl genrsa -out /etc/ssl/private/myhost.key 4096 chmod og-rwx /etc/ssl/private/myhost.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 your server’s full qualified domain name (FQDN, i.e. www.abc.com) as the certificate’s common name here. Refer to What Is a Certificate?
for more details.
If you don’t 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 don’t 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 -sha512 \ -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
That’s all.[9] 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.
If You Are an Unprivileged User
Set up Your OpenSSL Environment
# Set up the relevant directories mkdir -p ~/etc mkdir -p ~/etc/ssl mkdir -p ~/etc/ssl/private chmod og-rwx ~/etc/ssl/private mkdir -p ~/etc/ssl/certs mkdir -p ~/etc/ssl/crl mkdir -p ~/etc/ssl/newcerts mkdir -p ~/tmp # Set up your OpenSSL configuration file[10] cp /usr/share/ssl/openssl.cnf ~/etc/ssl # 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
Now modify your ~/etc/ssl/openssl.cnf. Change the line
dir = ./demoCA # Where everything is kept
to
dir = ~/etc/ssl # Where everything is kept
Create a Root CA
If you have created your root CA before, don’t do this step again. Otherwise, all your issued certificates will become invalid and you’ll 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 -aes256 -out ~/etc/ssl/private/myrootca.key 4096 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 server’s full qualified domain name (FQDN, i.e. www.abc.com) as the certificate’s common name here. Refer to Alternative Methods to Create SSL/X.509 Certificates
for more details.
If you don’t 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.
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 -sha512 \ -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
That’s 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.
Create a Server Certificate
Assuming you are creating a server certificate for myhost.
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.
CAUTION: Do not set any password for the private key of your server certificate. Your SSL service will ask you for that password when it starts and reads its certificate private key. When your system boots and starts each server one by one, it will stop for the password from the keyboard for each SSL service that reads that private key. Now your server may be colocated at some IDC. You may leave the office during the weekend. You may not be able to attend to its keyboard at all times. You will not be happy to see if it cannot keep booting, waiting for a password from the keyboard, after a remote reboot or a crashed auto-reboot.
# Create an RSA private key openssl genrsa -out ~/etc/ssl/private/myhost.key 4096 chmod og-rwx ~/etc/ssl/private/myhost.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 your server’s full qualified domain name (FQDN, i.e. www.abc.com) as the certificate’s common name here. Refer to What Is a Certificate?
for more details.
If you don’t 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 don’t 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 -sha512 \ -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
That’s 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.
Configure the Operating Systems
Many operating systems have a common system certificate database, to store all the recognized CAs and certificates in a central place. We can add our own root CA into this common certificate database, and then our root CA will be available to all the programs that ultilize this certificate database.
Linux/*BSD/UNIX
MS-WINDOWS
MS-WINDOWS has a common system certificate database. Go to the [Control Panel]. There’s 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. There’s 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. That’s 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.
Configure the Servers
There are 2 types of SSL connections: The first one is the traditional SSL, and the second is the newer TLS.
For the traditional SSL, both sides enter SSL as soon as the client is connecting to the server. The whole connection is then encrypted. There’s a disadvantage for this: In order not to confuse the client program, we have to allocate another TCP port for our SSL connection, and configure the client program to connect to that SSL TCP port. HTTP and HTTPS is an example for this.
For the newer TLS, the client sends a STARTTLS command to the server after it has connected to the server. If the server understands it, both sides will enter SSL and the encryption will begin. Otherwise, the client will continue the unencrypted connection as before. The benefit here is that: Users do not need to change the TCP port of the client programs. It can automatically enter SSL as possible or fall back to the unencrypted connection. The compatibility is a lot better. There is no need to allocate another TCP port. But it also has a disadvantage: The connection will always be valid with or without SSL. Even if the server’s certificate is invalid and SSL is unavailable, the connection can go on. Certificate verification becomes meaningless. We are only benefited from the connection encryption. The identity of the server will not be really verified.
We will discuss each protocol in the following sections.
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 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 httpd.conf as follows after you have successfully installed mod_ssl:
…
## 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>
…
Then, check your httpd.conf:
httpd -t
If everything is OK, restart your httpd and you’ll have a SSL web site now.
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
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
Set up your /etc/qpopper-s.conf as follows:
# qpopper-s.conf: Configuration file for Qpopper POP3S(995) set clear-text-password = tls set statistics = true set tls-support = alternate-port set tls-private-key-file = /etc/ssl/private/myhost.key set tls-server-cert-file = /etc/ssl/certs/myhost.crt
Then, run these 2 commands with the root privilege:
popper -f /etc/qpopper.conf popper 995 -f /etc/qpopper-s.conf
That’s all. Try:
ps ax | grep popper
You’ll see 2 popper processes running simultaneously, each with a different set of arguments. Try:
netstat -ap | grep popper
You’ll see 2 popper processes on POP3(110) and POP3(995), seperately.
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 won’t find any infomation for SMTPS support in the 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 won’t 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.
To enable Sendmail’s SSL support, add the follows to devtools/Site/site.config.m4 before you compile your Sendmail:
# 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')
Compile and install Sendmail:
# Compile Sendmail ./Build # Install Sendmail make install
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
Rebuild the configuration file:
m4 m4/cf.m4 config.mc > config.cf cp -f config.cf /etc/mail/sendmail.cf
Now we restart the Sendmail. It will start to do SMTPS/TLS SSL. Try:
netstat -ap | grep sendmail
You’ll see a same sendmail process on both SMTP(25) and SMTPS(465)[18] 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 everyone’s mail 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 don’t. It cannot read our server private key now. What can we do?
We don’t want our Sendmail to be setuid-root. We don’t 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 up the relevant directories mkdir -p /etc/mail/private chgrp smmsp /etc/mail/private chmod o-rwx /etc/mail/private mkdir -p /etc/mail/certs # Create an RSA private key openssl genrsa -out /etc/mail/private/myhost-msp.key 4096 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 -sha512 \ -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
Add the follows to your m4 file submic.mc:
… dnl Sendmail STARTTLS SSL/TLS support define(`confCACERT_PATH', `/etc/ssl/certs') define(`confCACERT', `/etc/ssl/certs/myrootca.crt') define(`confCLIENT_CERT', `/etc/mail/certs/myhost-msp.crt') define(`confCLIENT_KEY', `/etc/mail/private/myhost-msp.key') define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile') …
Rebuild the configuration file:
m4 m4/cf.m4 submit.mc > submit.cf cp -f submit.cf /etc/mail/submit.cf
That’s all. You don’t 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.
… 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 …
Configure the Browser
Mozilla/Netscape 6 or Newer
Mozilla and Netscape 6 or newer has a common certificate database for its mail and browser programs. Starting from the tool bar, from [Edit], [Preferences...], a window titled [Preferences] will pop up. Expand the [Privacy & Security] menu in the left side, and click on the [Certificates]. The title in the right side will become [Certificates]. There’s a button [Manage Certificates...] in the middle. Click on it. Another window titled [Certificate Manager] will pop up. This is the place where Mozilla and Netscape manage their certificates.[21][22]
To add our root CA in, put our root CA myrootca.crt onto a web server. Move to that address with Mozilla/Netscape browser. A window titled [Downloading Certificate] will pop up. Check all the 3 options: [Trust this CA to identify web sites], [Trust this CA to identify email users], [Trust this CA to identify email software developers]. Then click on [OK]. That’s all.
If you are using Mozilla/Netscape under MS-WINDOWS, you can also add our root CA in by copying our root CA to the WINDOWS and typing the full path of our root CA in the Mozilla/Netscape address bar.
The root CA imported into the Mozilla/Netscape browser will also be avaible to the Mozilla Mail and Netscape Mail & Newsgroups to verify the certificates.
Internet Explorer
Internet Explorer ultilizes WINDOWS’s 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.
Start your Opera. Starting from the tool bar, from [File], [Preferences...], 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. That’s all.
Lynx
Until the time this article is written, Lynx (2.8.4) does not verify SSL certificates of the servers.
Configure the E-mail Programs
Mozilla/Netscape 6 or Newer
To receive mails using SSL, start your Mozilla/Netscape Mail & Newsgroups. Starting from the tool bar, from [Edit], [Mail & Newsgroups Account Settings...], a window titled [Mail & Newsgroups Account Settings] will pop up. Click the [Server Settings] below the account you want to configure in the left side menu. Fill your POP3 mail server’s full qualified domain name (FQDN) in the [Server Name:] at the right side of the window, and check the [Use secure connection (SSL)] below. Then click [OK]. That’s all.
To send mails using SSL, start your Mozilla/Netscape Mail & Newsgroups. Starting from the tool bar, from [Edit], [Mail & Newsgroups Account Settings...], a window titled [Mail & Newsgroups Account Settings] will pop up. Click the [Outgoing Server (SMTP)] in the left side menu. The title of the right side will become [Outgoing Server (SMTP) Settings]. Fill your POP3 mail server’s full qualified domain name (FQDN) in the [Server Name:] at the right side of the window. There’s a [Use secure connection (SSL):] below. Choose [When available] there. Then click [OK]. That’s all.
Mozilla/Netscape Mail & Newsgroups ultilizes the certificate database of Mozilla/Netscape 6. Our root CA is available as long as it is imported into this certificate database. Refer to Configure Mozilla/Netscape 6 or Newer
for more details.
Netscape 4 or Earlier
Netscape 4 or earlier does not support SSL.
Outlook Express 5.5/6
To receive mails using SSL, start your Outlook Express. Starting from the tool bar, from [Tools], [Accounts...], a window titled [Internet Accounts] will pop up. Click on the account you want to configure at the left side, and click the [Properties] at the right side. A window titled [XXXXXX Properties] will pop up. Click on the [Servers] tab at the top to move to the [Servers] page. Fill your POP3 mail server’s full qualified domain name (FQDN) in the [Incoming mail (POP3):]. Now click the [Advanced] tab at the top to move to the [Advanced] page. Check the [This server requires a secure connection (SSL)] below the [Incoming mail - POP3:]. Then click [OK]. That’s all.
To send mails using SSL, start your Outlook Express. Starting from the tool bar, from [Tools], [Accounts...], a window titled [Internet Accounts] will pop up. Click on the account you want to configure at the left side, and click the [Properties] at the right side. A window titled [XXXXXX Properties] will pop up. Click on the [Servers] tab at the top to move to the [Servers] page. Fill your SMTP mail server’s full qualified domain name (FQDN) in the [Outgoing mail (SMTP):]. Now click the [Advanced] tab at the top to move to the [Advanced] page. Check the [This server requires a secure connection (SSL)] below the [Outgoing mail - SMTP:], and change the port number in the [Outgoing mail - SMTP:] to 465. Then click [OK]. That’s all.
Outlook Express ultilizes WINDOWS’s 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.
Outlook Express 4/5
To receive mails using SSL, start your Outlook Express. Starting from the tool bar, from [Tools], [Accounts...], a window titled [Internet Accounts] will pop up. Click on the account you want to configure at the left side, and click the [Properties] at the right side. A window titled [XXXXXX Properties] will pop up. Click on the [Servers] tab at the top to move to the [Servers] page. Fill your POP3 mail server’s full qualified domain name (FQDN) in the [Incoming mail (POP3):]. Now click the [Advanced] tab at the top to move to the [Advanced] page. Check the [This server requires a secure connection (SSL)] below the [Incoming mail - POP3:]. Then click [OK]. That’s all.
To send mails using SSL, start your Outlook Express. Starting from the tool bar, from [Tools], [Accounts...], a window titled [Internet Accounts] will pop up. Click on the account you want to configure at the left side, and click the [Properties] at the right side. A window titled [XXXXXX Properties] will pop up. Click on the [Servers] tab at the top to move to the [Servers] page. Fill your SMTP mail server’s full qualified domain name (FQDN) in the [Outgoing mail (SMTP):]. Now click the [Advanced] tab at the top to move to the [Advanced] page. Check the [This server requires a secure connection (SSL)] below the [Outgoing mail - SMTP:], and change the port number in the [Outgoing mail - SMTP:] to 465. Then click [OK]. That’s all.
Outlook Express 4/5 does not verify SSL certificates of the servers.
Eudora 5.1 or Newer
Eudora has bad SSL design.
There is a [Certificate Infomation Manager] in Eudora after Eudora 5.1, that can manage the Eudora certificate database. But there’s no way to go to this [Certificate Infomation Manager] directly[23]. You have to check your mails once with SSL first, then you can enter this [Certificate Infomation Manager][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 don’t have to configure SSL specifically. But there’s a big problem in Eudora’s STARTTLS approach. If, after STARTTLS succeeds and both sides enter SSL, Eudora fails to verify the mail server’s 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 user’s previously-working Eudora will stop working without asking the user. Your innocent Eudora users may panic. That’s another big problem with Eudora’s 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 there’s really any problem with the certificate itself.
CAUTION: OpenSSL’s 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 server’s 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]. That’s all.
To send mails using SSL, start your Eudora. Starting from the tool bar, from [Tools], [Options...], a window titled [Options] will pop up. Click on [Sending Mail] from the [Category] left side menu. Fill your SMTP mail server’s 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]. That’s all.
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 CA’s DER file myrootca-der.crt and double click to import it. That’s 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 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 [Incoming] section, fill your POP3 mail server’s full qualified domain name (FQDN) in the [Server], and check the [TLS] beside the [Protocol] menu below. Then click [OK]. That’s all.
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 server’s full qualified domain name (FQDN) in the [Server], and check the [TLS] beside the [Protocol] menu below. Then click [OK]. That’s 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.
Configure Programs That Do Not Support SSL/TLS
Help! My program does not support SSL/TLS!
It’s OK. We can use a SSL wrapper to build the SSL connection first, forward the commands from our program to the server through this SSL connection, and forward the response from the server through this SSL connection back to our program. By this way, we can enable our non-SSL programs to send and receive information through this SSL-encrypted connection. We’ll introduce an SSL wrapper below:
Stunnel
You can downnload Stunnel from its web site at http://www.stunnel.org/. It’s 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 [smtps] accept = localhost:50025 connect = my.mail.server:465
- 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:
you’ll see something like this:netstat -an
Double click on the small Stunnel icon at the right of the tool bar will display the logs of Stunnel.TCP 127.0.0.1:50025 0.0.0.0:0 LISTENING TCP 127.0.0.1:50110 0.0.0.0:0 LISTENING
- 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.
That’s 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 there’s 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.
Review and Discussion
Introduction to SSL/X.509
SSL adopts the X.509 hierarchical certificate system.
In X.509, every valid certificate has a signature. Every valid server certificate at the bottom level has a signature from its administrative CA. It means that this CA had verified that the infomation on this certificate is correct. Every intermediate CA has also a signature from its administrative root CA. It means that this root CA had authorized this CA to sign certificates. But root CAs have no administrative CAs anymore. No administrative CAs can sign root CAs. Root CAs have to 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.
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.
Warning: Invalid Certificate
At the beginning of this article we have discussed how to create our own root CA. Since this CA is made by ourself, the SSL program has no way to know it. Then, the signature on our certificate in the second step will not be recognized by the SSL program, either. Our SSL program will always issue a certificate invalidity warning.
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.
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 for a certificate from one of the major CAs. It costs about USD 1,000 per year.
Wait! What Data?
Wait! In the last step of your illustration, it says
OK. This is the data for you.
But I haven’t fill in any data yet! How can it send my data by itself? What does it send? Will it automatically send my e-mail address, credit card number, my passwords to the server?
It sends the server the symmetric key for the following encrypted connection.
The asymmetric public/private key encryption is safe. You can release your public key to the world. Just keep your private key secretly. If someone wants to send you secret infomation and encrypts it with your public key, there’s no one in the world but who knows your private key (that is, you) can decrypt and see it. But it’s slow. On the contrary, the traditional symmetric encryption is fast. But both of you have to know the same key. It risks the danger that your key might be leaked out when you tell it to the other.
SSL uses a two-step encryption: In the beginning it uses the asymmetric public/private key encryption to send the other end the symmetric key of the following actual communication.
Then, it uses this symmetric key to communicate with each other. The actual encryption in use is symmetric encryption. This symmetric key is generated randomly and sent to the other end with the public/private key encryption. It changes upon each connection. Using this two-step theme, we can enjoy the fast encryption speed without worrying the disclosure of the encryption key.
So, SSL is safe now?
Now that the SSL site’s certificate is valid, with a signature from a most trustworthy CA. Is it safe to send my credit card number now?
No.
Watch closely to the previous section on Introduction to SSL/X.509
. In SSL/X.509, the signature of the CA merely assures that This public key really belongs to this very server of this very company.
In other words, it only guarantees that Your credit card number will be handed to this very company. No other people can peek at your communication.
But this does not imply that This company is honest. It will not abuse the received credit card number. It will not side record your credit card number. It will not request for additional payment. It will not sell your number to anyone.
This also does not imply that This company takes great care on the server security. Nobody will be able to intrude this server and install a credit card number recorder stealthily.
That’s right. SSL can only ensure that the received public key is not a fake. It cannot ensure that this company itself is honest. Even that this company is honest, it may still be the target of some bad intruder.
OK, then, what should I do now? How can I send my infomation safely?
You’re always careful when you deal with an unfamiliar store in the real world. It’s 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 Digital Signature?
A digital signature is a piece of digest code, resulted from some source infomation and a private key. It is calculated with some digest hash algorithm (like SHA1). As long as the source infomation is changed, the resulted digest will be different, too. You can check the digest by a private key with its corresponding public key. Verifying the source infomation with the resulted digest by the corresponding public key, you can know that whether this source infomation is the same as the one signed by this private key, and whether this infomation was tempered by somebody.
It’s much the same like making a big signature on the whole contract. People know your handwriting. They will know whenever someone writes over this contract.
Since digital signatures can be used to check whether the source information is temptered or not, we can apply them to the certificates. The CA verifies if the owner infomation came with this public key is correct. If the infomation is correct, the certificate authority will use its private key to sign this applicant, as a certificate. Then, when someone receives this public key, she can verify its CA signature to know if its owner infomation is correct, if this key is owned by this company, and thus, if this server is indeed owned by this company.
What Is a Certificate?
A certificate is a public key, attached with its owner’s 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 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.
What is a Root CA?
Root CA is also a part of the X.509 system. It is itself a CA, too. Its difference from an ordinary CA is that, its purpose is not to issue certificates directly, but to authorize some intermediate CAs the priviledge to issue certificates. Refer to the illustration in Introduction to SSL/X.509
.
Since root CAs are highest, no more higher governmental CA can sign them. They can only have their own signatures. There is no another’s signature on a root CA, nobody to guarantee that a root CA is valid. There is no way to further verify a root CA. Thus, an SSL program must recognize some trustworthy root CAs in advance. It must know the public keys of these trustworthy root CAs.
Since root CAs cannot be further verified, they have to be world-wide famous for its trustworthiness. If there’s an suspicious root CA sneaking into the SSL prorgam’s known root CA list, the security will be void whenever the program meets a certificate issued by that suspicious root CA. Thus, in X.509, an SSL program must take great care protecting its known root CA list. It should not let its user add new root CAs casually.
How to Fill in the Certificate Request?
Consult the following example if you have no idea how to fill in the certificate request.
You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:TW State or Province Name (full name) [Some-State]:Taiwan Locality Name (eg, city) []:Taipei City Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tavern IMACAT's Organizational Unit Name (eg, section) []:Owner Common Name (eg, YOUR name) []:Tavern IMACAT's Email Address []:imacat@mail.imacat.idv.tw Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
- You have to fill everything in English (ASCII characters). Only ASCII English characters are allowed in X.509 certificates.
- Country Name 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/4096
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 don’t need a password for the request. Leave it blank.
- An optional company name is name of the certificate application agent. Leave it blank, too.
Review to the X.509 Certificate System
X.509 certificate system is a hierarchy. There are a few topmost trustworthy root CAs that are known in advance.
(To be continued…)
by imacat, first written 2002-01-09, last updated 2006-04-06
