The SSL Keypair Certification Process
By Steve Hartman and Elaine Smith, 4D, Inc. Technical Support
Technical Note 01-14
Technical Notes for Technical Notes for 01-03 March 2001
Introduction
SSL is an Internet protocol which specifies how to pass secure communications between your server and HTTP clients, such as a browser. This provides world-class security for your web site, allowing you to accept credit card numbers, and serve medical records, human resource information, or other sensitive data without fear of interception.
Both 4D and WebSTAR use the RSA Algorithm as excepted by the US Federal Advanced Encryption Standard.
RSA Encryption Cryptography is one of five Encryption Algorithms qualified for the A. E. S. and is widely use for authentication and encryption in the computer industry.
This tech note covers the basics of SSL Technology, the generation of Key Pairs by 4D and WebSTAR as well as the installation of SSL for 4D and WebSTAR.
How SSL works
An Introduction to Key Cryptography
Public key encryption is a technique that uses a pair of asymmetric keys for encryption and decryption. Each pair of keys consists of a public key and a private key. The public key is made public by distributing it widely. The private key is never distributed; it is always kept secret.
Data that is encrypted with the public key can be decrypted only with the private key. Conversely, data encrypted with the private key can be decrypted only with the public key. This asymmetry is the property that makes public key cryptography so useful.
Using Public Key Cryptography for Authentication
Authentication is the process of verifying identity so that one entity can be sure that another entity is who it claims to be. In the following example involving Alice and Bob, public key cryptography is easily used to verify identity. The notation {something}key means that something has been encrypted or decrypted using key.
Suppose Alice wants to authenticate Bob. Bob has a pair of keys, one public and one private. Bob discloses to Alice his public key (the way he does this is discussed later). Alice then generates a random message and sends it to Bob:
A->B Random-message
Bob uses his private key to encrypt the message and returns the encrypted version to Alice:
B->A {random-message} bob's-private-key
Alice receives this message and decrypts it by using Bob's previously published public key. She compares the decrypted message with the one she originally sent to Bob; if they match, she knows she's talking to Bob. An imposter presumably wouldn't know Bob's private key and would therefore be unable to properly encrypt the random message for Alice to check.
Unless you know exactly what you are encrypting, it is never a good idea to encrypt something with your private key and then send it to somebody else. This is because the encrypted value can be used against you (remember, only you could have done the encryption because only you have the private key).
So, instead of encrypting the original message sent by Alice, Bob constructs a message digest and encrypts that. A message digest is derived from the random message in a way that has the following useful properties:
The digest is difficult to reverse. Someone trying to impersonate Bob couldn't get the original message back from the digest.
An impersonator would have a hard time finding a different message that computed to the same digest value.
By using a digest, Bob can protect himself. He computes the digest of the random message sent by Alice and then encrypts the result. He sends the encrypted digest back to Alice. Alice can compute the same digest and authenticate Bob by decrypting Bob's message and comparing values.
The technique just described is known as a digital signature. Bob has signed a message generated by Alice, and in doing so he has taken a step that is just about as dangerous as encrypting a random value originated by Alice. Consequently, our authentication protocol needs one more twist: some (or all) of the data needs to be originated by Bob.
| A->B | Hello, are you Bob? | |
| B->A | Alice, This Is Bob. | |
| { digest [Alice, This Is Bob] } bob's-private-key |
When he uses this protocol, Bob knows what message he is sending to Alice, and he doesn't mind signing it. He sends the unencrypted version of the message first, "Alice, This is Bob." Then he sends the digested-encrypted version second. Alice can easily verify that Bob is Bob, and Bob hasn't signed anything he doesn't want to.
Handing Out Public Keys
How does Bob hand out his public key in a trustworthy way? Let's say the authentication protocol looks like this:
| A->B | Hello | |
| B->A | Hi, I'm Bob, bob's-public-key | |
| A->B | prove it | |
| B->A | Alice, This Is Bob | |
| { digest [Alice, This Is Bob] } bob's-private-key |
With this protocol, anybody can be Bob. All you need is a public and private key. You lie to Alice and say you are Bob, and then you provide your public key instead of Bob's. Then you prove it by encrypting something with the private key your have, and Alice can't tell you're not Bob.
Now suppose Alice and Bob have a mutual friend, Ted. Ted has signed Bob's key, and both Alice and Bob have a verified copy of Ted's key.
When Alice examines Bob's key she observes that his key was signed by Ted, Alice trusts that Ted is reliable when it comes to signing other people's keys. Therefore Alice can be fairly certain that the key belongs to Bob.
In this way, by verifying and signing keys wherever possible, a "web of trust" may be built up. With trusted keys vouching for new keys. Of course the weak point is now the person who signs a key.
This is similar to the way the standards community has invented an object called a certificate. A certificate has the following content:
The certificate issuer's name
The entity for whom the certificate is being issued (a.k.a. the subject)
The public key of the subject
Some time stamps
The certificate is signed using the certificate issuer's private key. Everybody knows the certificate issuer's public key (that is, the certificate issuer has a certificate, and so on…). Certificates are a standard way of binding a public key to a name.
By using this certificate technology, everybody can examine Bob's certificate to see whether it's been forged. Assuming that Bob keeps tight control of his private key and that it really is Bob who gets the certificate, then all is well. Here is the amended protocol:
| A->B | Hello | |
| B->A | Hi, I'm Bob, bob's-certificate | |
| A->B | prove it | |
| B->A | Alice, This Is Bob | |
| { digest [Alice, This Is Bob] } bob's-private-key |
A bad guy – lets call her Carol – can do the following:
| A->C | Hello | ||
| C->A | Hi, I'm Bob, bobs-certificate | ||
| A->C | prove it | ||
| C->A | ???? |
But Carol can't satisfy Alice in the final message. Carol doesn't have Bob's private key, so she can't construct a message that Alice will believe came from Bob.
The GENERATE ENCRYPTION KEYPAIR Command
The first step to procuring a certificate is to generate a private key and a public key. This can be done with the command GENERATE ENCRYPTION KEYPAIR. The command GENERATE ENCRYPTION KEYPAIR generates a pair of RSA keys. The security system offered in 4D is based on keys designed to encrypt/decrypt information. They can be used within the SSL protocol, with 4D Web server (encryption and secured communications) and in all databases (for data encryption). Once the command has been executed, the BLOBs passed in the private key and public key parameters contain a new pair of encryption keys. The optional parameter length can be used to set the key size (in bits). The larger the key, the more difficult it is to break the encryption code. However, large keys require longer execution or reply time, especially within a SSL connection.
By default (if the length parameter is omitted), the generated key size is set to 512 bits, which is a good compromise for the security/efficiency ratio. To increase the security factor, you can change keys more often, for example every six months. You can generate 1024 bits keys to increase the encryption security but the Web application connections will be slowed down.
Notes:
If you generate keys in order to establish a SSL certificate request, pay attention to the fact that only 512 bits and 1024 bits key length are admitted.
Many browsers will not accept keys with a length greater than 512 bits.
Once the pair of keys has been generated, a text document can be produced (using the BLOB TO DOCUMENT command for example) and the keys can be stored in a safe place. The private key will have a header and footer like this:
-----BEGIN RSA PRIVATE KEY-----
(private key information)
-----END RSA PRIVATE KEY-----
and the public key will have a header and footer like this:
-----BEGIN RSA PUBLIC KEY-----
(public key information)
-----END RSA PUBLIC KEY----
Warning: The private key should always be kept secret.
About RSA, private key and public key
The RSA cipher used by GENERATE ENCRYPTION KEYPAIR is based on a double key encryption system: a private key and a public key. As indicated by its name, the public key can be given to a third person and used to decrypt information. The public key is matched with a unique private key, used to encrypt the information. Thus, the private key is used for encryption; the public key for decryption (or vice versa). The information encrypted with one key can only be decrypted with the other one.
The SSL protocol encryption functionalities are based on this principle, the public key being included in the certificate sent to the browsers (see section Web Services, Using SSL Protocol).
This encryption mode is also used by the first syntax of the ENCRYPT BLOB and DECRYPT BLOB commands. The public key should be confidentially published. It is possible to mix the public and private keys from two persons to encrypt information so that the recipient is the only person to be able to decrypt them and the sender is the only person to have encrypted them. This principle is given by the two commands ENCRYPT BLOB and DECRYPT BLOB second syntax.
The GENERATE CERTIFICATE REQUESTCommand
The next step to getting an SSL certificate is to use the command GENERATE CERTIFICATE REQUEST (secured prococol version 6.7). The GENERATE CERTIFICATE REQUEST command generates a certificate request in a text format which can be used directly by certificate authorities such as Verisign® or Thawte®. The certificate plays an important part in the SSL secured protocol. It is sent to each browser connecting in SSL mode. It contains the "ID card" of the Web site (made from the information entered in the command), as well as its public key allowing the browsers to decrypt the received information. Furthermore, the certificate contains various information added by the certificate authority, which guarantees its integrity.
The certificate request uses keypairs generated with the GENERATE ENCRYPTION KEYPAIR command and contains various information. The certificate authority will generate its certificate combining this request with other parameters. You can store this request in a text file, for example using the BLOB TO DOCUMENT command, to submit it to the certificate authority.
Warning: The private key is used to generate the request but should NOT be sent to the certificate authority.
Example Database
The "Certificate request" form contains the six fields necessary for a standard certificate request. The "Create Keypair" button will create the private key and the public key. The "Generate Certificate" button creates a document on disk containing the certificate request. The "Private.txt" document containing the private key (generated with the GENERATE ENCRYPTION KEYPAIR command) should be located on the disk:
Instructions for filling out form:
1. Fill in the fields of the form
Example:
CommonName: www.4d.com
Country: USA
City: San Jose
State or Province: California
Company: 4D, Inc.
Unit: Tech Support
2. Click the Create Keypair button. This will ask you for the name you want to give to the private key for example private.txt then it will ask for a name of the public key, for example "public.txt".
3. Click the Generate Certificate button. It will ask you to select the private key document.
4. Click Done and exit the program.
You will then have a .txt document called "Request.txt" that can be opened and the contents copied and pasted into the web form area for submission.
Submitting the request for a certificate
A 4D Web server working in secured mode means that you need a digital certificate from a certification authority. This certificate contains various information such as the site ID as well as the public key used to communicate with the site. This certificate is transmitted to the Web browsers connecting to this site. Once the certificate has been identified and accepted, the communication is made in secured mode.
Note: A browser authorizes only the certificates issued by a certification authority referenced in its properties.
The certification authority is chosen according to several criteria. If the certification authority is well known, many browsers will authorize the certificate, however the price to pay will be expensive.
To get a SSL certificate
1. Generate a private key using the GENERATE ENCRYPTION KEYPAIR command. Name the private key text file key.pem.
Warning: For security reasons, the private key should always be kept secret. Actually, it should always remain with the Web server machine. The key.pem file must be placed in the Database structure folder.
2. Use the GENERATE CERTIFICATE REQUEST command to issue a certificate request.
3. Send the certificate request to the chosen certificate authority.
To fill in a certificate request, you might need to contact the certification authority. The certification authority checks that the information transmitted are correct. The certificate request is generated in a BLOB in a text file. This format allows you to copy and paste the keys as text and to send them via e-mail without modifying the key content. For example, you can save the BLOB containing the certificate request in a text document (using the BLOB TO DOCUMENT command), then open and copy and paste its content in a mail or a Web form to be sent to the certification authority.
Once you get your certificate, create a text file named "cert.pem" and paste the contents of the certificate into it.
You can receive a certificate in different ways (usually by e-mail or HTML form). The 4D Web Server accepts all platform-related text formats for certificates (Mac OS, PC, Linux...).
5. Place the "cert.pem" file in the Database structure folder (the same folder with key.pem).
The Web server can now work in a secured mode. A certificate is valid between 6 months to a year.
Note: 4D only uses the 128-bit and 40-bit Encryption Algorithm.
SSL installation and activation within 4D
The SSL protocol integration within 4D has been made at the network components level. The following components should be installed:
4DNCTCP.DLL: DLL used by the TCP/IP protocol. This file must be the same version as 4D used for SSL. This file should be placed in the 4D folder inside the system folder for Windows (C:\Windows\4D\). On Mac OS, the network components are incorporated into 4D.
4DSLI.DLL: Secured Layer Interface dedicated to the SSL management.
This file should be placed in the [4D Extensions] folder of the 4D application that publishes the database.
Note: This file must be renamed 4DSLI.DLL for SSL to work. 4DSLI.DLL is also necessary to use the encryption commands ENCRYPT BLOB and DECRYPT BLOB.
key.pem (Web Server only): document containing the private encryption key for Web server publishing. This file should be placed in the database folder.
cert.pem (Web Server only): document containing the "certificate" for Web server publishing. This file should be placed in the database folder.
Once these files have been installed, the Web server connections as well as the client/server connections (if any) can be done in a secured mode. By default, the SSL connections are activated for the Web server and deactivated for the client/server connections. SSL settings can be found in the Database Properties dialog on the "Connections" page. The TCP port dedicated to SSL data exchange is 443. As a result, you cannot install more than one Web server using SSL on a machine. The TCP port defined in the Web Server I page of the Database Properties will be used for standard mode Web server connections.
Generally speaking, the Database Properties defined for the 4D Web Server management (password, timeout, cache size, etc.) are applied, regardless of the connection mode.
Browser connection with SSL
A dialog box is displayed indicating that the browser connects to the Web server in a secured mode. If the user clicks OK, the Web server sends the certificate to the browser. The browser and the Web server then decide the encryption algorithm used for the connection. The server offers several symmetric encryption algorithms (RC2, RC4, DES...). The most powerful common algorithm is used. The level of encryption allowed depends on current laws in the country of use. By default, 4D provides an "Export" version of the encryption system library whereby symmetric algorithms are limited to 40 bits.
On the browser's side, two elements indicate that you are working in a secured mode:
The URL displayed in the address area starts with HTTPS: instead of HTTP. The protocol name "https" indicates that the connection is made with SSL.
A closed padlock symbol is displayed at the browser bottom page. The user can double-click the padlock to get information on the connection (certificate, etc.).
Using SSL in existing Web Servers
Using SSL with 4D Web server does not require any specific system configuration. However, you should keep in mind that a SSL Web server can also work in a non-secured mode. The connection mode can switch to another mode if the browser requires so (for example, in the browser URL area, the user can replace "HTTPS" by "HTTP"). The developer can forbid or redirect requests made in a non-secured mode. The command Secured Web connection allows you to get the current connection mode. Similarly, when updating a 4D Web server with a 6.7 SSL version, make sure that the full URLs, placed in pages and referencing other pages from the same site, start with "HTTPS", otherwise the connection will switch to a non-secured mode.
Note: For the best implementation of SSL, use version 6.7.1 or above.
WebSTAR Server Suite SSL
Secure Socket Layer Protocol
WebSTAR SSL includes a full implementation of the Secure Sockets Layer (SSL) protocol, which provides server authentication, data encryption, and message integrity. These combine to keep the HTTP data truly secure as it travels across the Internet.
The Secure Sockets Layer Protocol, developed by Netscape, uses authentication and encryption technology developed by RSA Data Security Inc.
SSL is layered below application protocols such as HTTP and above TCP/IP. When SSL is implemented in both the client and the server software, all data is encrypted before it is transmitted.
WebSTAR Server Suite SSL supports SSL versions 2 and 3, and is based on the OpenSSL library.
WebSTAR SSL Encryption Ciphers: US and International
The U.S Domestic version of WebSTAR SSL implements the encryption described below.
RC4-128: The 128-bit version of the RC4 stream encryption algorithm provides very high-level encryption protection.
3DES: Triple DES, encrypted three times with three different DES keys. This is a much more secure than DES and slightly less secure than RC4-128. This encryption cipher is much slower to process of encryption.
DES: DES encryption is required by some United States government agencies. Allowing only a 56-bit key, DES provides less protection than RC4-128. It is also slower.
International
RC4-40: The International version of SSL uses a 40-key size for the RC4 stream encryption algorithm. Although this version contains a lower level of encryption protection, RC4-40 is still a formidable cipher.
DES-40: The International version of SSL uses the same algorithm as the DES encryption, and takes the same amount of time to process, with a 40-bit key.
MAC- only (no encryption): This provides message authentication only: it proves to the browser that the page was served by your server, but does not encrypt the HTML data, so anyone monitoring your data stream could see the page.
The U. S. government laws are changing in that it use to be that government prevents the export of RC4-128 and some versions of DES encryption software. Laws have changed and we will be shipping our WebSTAR Server Suite SSL with support for 128-bit encryption in our next release of WebSTAR Server Suite 4.4.
How Browsers Access A Secure Server
To connect to a secure page you must first connect to a secure server. In your Browser type in the location URL: https://www.domain.com/secure/securepage.html. The letter "s" in the url indicates the connection will be made secure.
Not visible to you, the browser behind the scenes makes a connection to the secure Port, which for a secure server would be Port 443. Once the connection has been established, the browser and the server negotiation begins. The browser sends a message to the web server with instructions on what encryption cipher it uses and the server will use the strongest cipher it has available.
If your browser is a 40-bit browser, the server encrypts the data at the highest level ciphers it has available. This would also be based upon your having the RC4-40 bit encryption enabled in the WebSTAR SSL Security encryption option. To ensure that all browser can connect securely to your server, enable all the encryption ciphers except MAC, which is no encryption but message authentication. WebSTAR determines which algorithm to use in this order.
WebSTAR evaluates in this order:
1 RC4-128
2 3DES
3 DES-56
4 RC4-40
5 DES-40
6 MAC (Authentication, no encryption)
Once WebSTAR has found the strongest encryption cipher they can both use, the server sends its certificate proving who the owner is and uses that to create the encryption key. This in fact makes the connection secure.
Next, the browser encrypts the data it sends to the server, such as credit card numbers, and decrypts data it gets from the server, such as medical data or bank records.
If you attempt to request a secure connection and get an error displayed, "No Common Encryption Algorithm", this error message means you have not enabled the encryption needed for this connection. Log on with the WebSTAR Admin application and make sure that all encryption except MAC is enabled.
In order to make your WebSTAR server a secure server, SSL requires a certificate. A certificate is issued by a trusted third party known as the Certificate Authority.
The certificate signifies that an independent party such as VeriSign/Thawte has verified that the information in the certificate accurately represents who it claims to represent, and that communications can be encrypted using the certificate's public/private key. WebStar is compatible with the PKCS Server Gated Cryptography and Netscape formatted certificates, which is the most common standard today. Below you will find examples of the different types of certificates that you can request from the Authorities covered in this Tech Note.
Verisign/Thawte Certificates
Verisign/Thawte offers several encryption certificates, below are a couple examples in which to choose from. For more information on Verisign/Thawte certificates go to http://www.verisign.com/.
Secure Site ID: The encryption level is determined by the browser. For example, if the browser is a 128-bit browser, then the encryption will be 128 bits. If the browser is a 40-bit browser, then the encryption will be 40 bits.
Secure Site Pro: The encryption is 128 bits regardless of the browser. For example, if the browser is a 128-bit browser, then the encryption will be 128 bits. If the browser is a 40-bit, the Global ID will "step up" the browser to a 128 bit encryption for that session.
How to create a Certificate Request in WebSTAR
Inside the WebSTAR Server Suite folder you find a Tools and Examples folder. Locate the SSL Tools folder and follow these procedures for generating your Certificate Signing Request, which you will send off to your Certificate Authority.
CSR Utility
The CSR Utility is an application for generating a key file containing a Private Key file for use with your secure server. It can also be used to generate a Certificate Signed Request for submission to your selected Certificate Authority.
To use the CSR Utility, follow these steps:
1. Launch the CSR Utility application by double-clicking its icon.
2. Enter a passphrase to protect the use of your Private Key file. Record this password as you will later need to enter it into the WebSTAR Admin application.
3. Select the Key Size you wish to generate. If you are unsure as to what Key Size to use, select 1024 — the default.
4. Click Create to generate your Private Key file. Generating a key can take a few minutes. By default the key file is named "Private Key". This file can be renamed if necessary.
5. Move this file into the WebSTAR Server Suite folder, storing it at the root of the appropriate virtual host folder.
6. Make a backup copy of the Private Key File and store it in a safe-deposit box or other safe place.
7. Select Certificate Request from the Action menu.
8. Enter the name of your Web site in the "Common Name" field, for example:
www.4D.com
Make sure that the Common Name you specify will be the actual host name of the HTTPS (SSL) server — it will be encoded into your signed Certificate and cannot be changed later without purchasing a new Certificate.
Furthermore, the host name must be the main "A name" entry for your machine on your DNS server. Your Certificate may have problems if you use an IP address or if the host name is a "CNAME" entry (DNS alias), for example. Contact your network administrator for guidance if necessary.
9. Enter the name of your organization in the "Organization" field, for example:
4D, Inc.
10. Enter the name of the department or other organization unit in the "Org Unit" field, for example:
Support
11. Enter the name of the city or town in which your organization is located in the "City/Locality" field, for example:
San Jose
12. Enter the name of the state or province in which the organization is located in the "State/Province" field, for example:
California
Do not abbreviate the state or province name: spell it out as shown above.
13. Enter a two-letter code for the country in which you are located in the "Country Code" field, for example:
US
Do not spell out the country name: use a 2-letter code. The code for the United States is US. For Canada, the code is CA. For a list of the standard international Certificate country codes, see
http://www.starnine.com/webstar/countrycodes.html
14. Enter the email address of the site's Webmaster in the "Email Address" field, for example:
webmaster@4D.com
15. In the Phone Number field, enter a phone number where the Certificate Authority can reach you, and enter your fax number in the FAX Number field.
16. Click Choose and select the Private Key file you created. This must be the original Private Key file. Once you have selected a Private Key file, the key file and the Certificate you will receive are a signed Certificate pair, and cannot be separated.
If you lose the Private Key file and generate a new one, your Certificate will no longer match. You will have to send a request to your Certificate Authority for a new Certificate, for which you may be charged. For this reason, be sure to keep backup copies of your files.
17. Enter the Private Key passphrase (entered in step 2 above).
18. Click the Create button to generate your encrypted Certificate Signed Request form. The application creates a file named Certificate Signed Request.
When the Certificate Authority has verified your documentation and processed the other information it requires, you will be notified that your Certificate request has been completed. Follow the Certificate Authorities instructions for obtaining the certificate data, then follow these steps:
1. Create a new text file in any text editor (including SimpleText).
2. Copy the certificate data, select your new text file, paste the coded text into it, and save the file. A good name for this file is "Certificate".
3. Move this certificate file into the WebSTAR Server Suite folder, storing it at the root of the appropriate host folder.
4. Make a backup copy of the Certificate file and store it in a safe-deposit box or other safe place.
5. See the WebSTAR Server Suite manual section "Configuring SSL Security" to continue setting up your secure server.
Using the Verisign/Thawte Certificate Authority
To be sure that your Certificate request is processed quickly, and that you are following the current procedures, we suggest that you check the instructions at:
http://www.verisign.com
Summary
SSL is an Internet protocol which specifies how to pass secure communications between your server and HTTP clients, such as a browser. This provides world-class security for your web site, allowing you to accept credit card numbers, server medical records, human resource information, or other sensitive data without fear of interception. This tech note provides an overview of the theory behind SSL and information on how to establish secure communications using 4D and WebSTAR.