SSL einrichten

[MegaBlue]

Kann mir mal einer ne Anleitung geben wie mann unter ISPCP RC3
die SSL.conf einrichtet?

Unter VHCS2 hat das alles noch funktioniert hier bekomme ich es einfach nicht zum laufen es liegt wohl an dem FCGI womit ich noch keine Erfahrung habe.

Hoffe mir kann Jemand helfen.

 

[Briese]

Hallo,
ein HowTo aus dem "isp-control.net" Forum:

[HowTo] SSL
(1) Generate your own Certificate Authority (CA).

Some steps in this document require priviledged access, and you'll want to limit access to the certs to all but the root user. So you may as well su to root and create a working directory that only root has read/write access to (for example: mkdir certwork, chmod 600 certwork). Go to that directory. In this step you'll take the place of VeriSign, Thawte, etc. You'll first build the CA key, then build the certificate itself.

The Common Name (CN) of the CA and the Server certificates should not match or else a naming collision will occur and you'll get errors later on. In this step, you'll provide the CA entries. In Step #2 below, you'll provide the Server entries. In this example, I just added "CA" to the CA's CN field, to distinguish it from the Server's CN field. Use whatever schema you want, just make sure the CA and Server entries are not identical.

CA:
Common Name (CN): http://www.somesite.edu CA
Organization (O): Somesite
Organizational Unit (OU): Development

Server:
Common Name (CN): http://www.somesite.edu
Organization (O): Somesite
Organizational Unit (OU): Development

If you don't have a fully qualified domain name, you should use the IP that you'll be using to access your SSL site for Common Name (CN). But, again, make sure that something differentiates the entry of the CA's CN from the Server's CN.

Code:

openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt


(2) Generate a server key and request for signing (csr).

This step creates an unsigned server key, and a request that you want it signed (the .csr file) by a Certificate Authority (the one you just created in Step #1 above.)

Think carefully when inputting a Common Name (CN) as you generate the .csr file below. This should match the DNS name, or the IP address you specify in the httpd.conf or ssl.conf (if this portion is separated outside of httpd.conf) for your server. If they don't match, client browsers will get a "domain mismatch" message when going to your https web server. If you're doing this for home use, and you don't have a static IP or DNS name, you might not even want worry about the message (but you sure will need to worry if this is a production/public server). For example, you could match it to an internal and static IP you use behind your router, so that you'll never get the "domain mismatch" message if you're accessing the computer on your home LAN, but will always get that message when accessing it elsewhere. Your call -- is your IP stable, do you want to repeat these steps every time your IP changes, do you have a DNS name, do you mainly use it inside your home or LAN, or outside?

Code:

openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr


(3) Sign the certificate signing request (csr) with the self-created certificate authority (CA) that you made earlier.

Note that 365 days is used here. After a year you'll need to do this again.

Note also that I set the serial number of the signed server certificate to "01". Each time you do this, especially if you do this before a previously-signed certificate expires, you'll need to change the serial key to something else -- otherwise everyone who's visited your site with a cached version of your certificate will get a browser warning message to the effect that your certificate signing authority has screwed up -- they've signed a new key/request, but kept the old serial number. There are a couple ways to rectify that. crl's (certificate revocation list) is one method, but beyond the scope of the document. Another method is for all clients which have stored the CA certificate to go into their settings and delete the old one manually. But for the purposes of this document, we'll just avoid the problem. (If you're a sysadmin of a production system and your server.key is compromised, you'll certainly need to worry.)

The command below does a number of things. It takes your signing request (csr) and makes a one-year valid signed server certificate (crt) out of it. In doing so, we need to tell it which Certificate Authority (CA) to use, which CA key to use, and which Server key to sign. We set the serial number to 01, and output the signed key in the file named server.crt. If you do this again after people have visited your site and trusted your CA (storing it in their browser), you might want to use 02 for the next serial number, and so on. You might create some scheme to make the serial number more "official" in appearance or makeup but keep in mind that it is fully exposed to the public in their web browsers, so it offers no additional security in itself.

Code:

openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

To examine the components if you're curious:

Code:

openssl rsa -noout -text -in server.key
openssl req -noout -text -in server.csr
openssl rsa -noout -text -in ca.key
openssl x509 -noout -text -in ca.crt


(4) Make a server.key which doesn't cause apache to prompt for a password.

Here we create an insecure version of the server.key. The insecure one will be used for when Apache starts, and will not require a password with every restart of the web server. But keep in mind that while this means you don't have to type in a password when restarting Apache (or worse -- coding it somewhere in plaintext), it does mean that anyone obtaining this insecure key will be able to decrypt your transmissions. Guard it for permissions VERY carefully.

Code:

openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key

More experienced system administrators out there can add more insight on this topic, but it appears that "chmod 600" is the minimal effective access that root retains on linux. By this, I mean that root retains read and write access to all files (but not executable rights, unless explicitly specified), regardless of their chmod settings. Execute rights are unnecessary for these files. Thus, I typically run SSL by chown'ing these files to root, and chmod'ing them to all zeros.. "chmod 000 {filename}". Root should still retain read/write access to them.

(5) Copy the files into position.

Check before you copy, and make backups if necessary. The following example is aimed at Apache 2.x configurations.

Code:

cp server.key /etc/apache2/ssl
cp server.crt /etc/apache2/ssl


(6) Tweak httpd.conf (Red Hat: ssl.conf) as needed.

Essentially you need to make sure your server name is configured, listening to the correct port, the ssl module is loaded and the engine is on, the locations of the server.crt and server.key files are properly referenced, and there's an existing document root (the path location) of your SSL site. There's more you can do, but this is the bare minimum. You'll need to make sure you've got at least the following lines properly configured. Note that they don't generally appear next to one another, so you'll need to hunt around a bit.

You should use the same server name or IP as the Common Name (CN) you picked while generating the Server csr in one of the earlier steps. This will prevent client web browsers from generating a message like "domain mismatch" whenever they visit the site. Replace the x's below with your IP or DNS name in /etc/apache2/httpd.conf.

ServerName xxx.xxx.xxx.xxx:443

You can listen to a different port, although 443 is standard for https. Replace the x's below with your IP or DNS name in /etc/apache2/ports.conf.

Listen xxx.xxx.xxx.xxx:443

Enable ssl.load

Code:

a2enmod ssl

Make sure the engine is on and referencing the server.crt and server.key files you moved into place at an earlier step. Of course it's possible to select different directory locations for the .crt and .key files. Always make sure you manage their permissions very carefully.

You'll then need to reference the DocumentRoot for the SSL portion of your website.

<VirtualHost xxx.xxx.xxx.xxx:443>
...
SSLEngine on
SSLCertificateFile /etc/httpd/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/ssl.key/server.key
...
</VirtualHost>

(7) Restart apache.

Code:

cd /etc/init.d
./httpd restart


Done -- test it out.