(I'm going to answer in unix idiom, as even on Windows boxes I rarely use anything but CygWin for my command line)
SSL certificate pairs are an example of public key cryptography. Another example of this is PGP. The idea is to use the public/private key pair to exchange a faster "session" key which is used to encrypt the actual information transfer. This means that at a minimum there must be a public/private key pair on one of the two systems. Often, this is the server, although the client (or both systems) can have the keys. The format used is based on the x.509 standard, which makes good reading material for insomniacs.
The SSL style of public keys depends upon establishing an absolutely trusted authority to certify that the certificate belongs to the person claiming it. This is called a certifying authority (or CA). Most (but not all) CA's will charge you money to digitally sign your certificate. For this reason, most systems only use this method for sites which must interact with the untrained public.
You can also create your own CA or generate a stand-alone self-signed certificate. If you expect to need multiple SSL services that will not be seen by the public (say you need many internal test systems for your web development firm), then you should set up your own CA. If this is a one-time problem, a self-signed certificate is all you need. (okay, technically all CA's are also self-signed, but for now we'll just concentrate on getting one cert into use before we try to set up a whole bunch of them)
I usually use OpenSSL to manage my certs. If all you need is just the one certificate, all you need to do is:
$ openssl req -new -x509 -keyout cert.crt -out cert.crt \
> -nodes -sha1 -days 3650
All of which means "Request a new x509 certificate and key. Put the private and public keys in the same file. Do not require a password on the private key (otherwise you will have to supply a password somehow each time you start up the service). Use the SHA1 hash to sign the request and set it not to expire for ten years." The program will prompt you for a bunch of answers, but the only really important one is:
Common Name (eg, YOUR name) []:
Which must match the DNS name that the IP you will be listening on resolves to from the client's point of view. So if your service is behind a NAT, you would need to give the name of the external gateway. (Okay, in point of fact, the connection will still work and be encrypted, but if you get into a bad habit now, you'll break a website some day down the road ...)
Your new cert.crt file is now ready for use on the server. For now we will not use a client-side certificate.
A basic SSL server looks like:
use strict;
use IO::Socket::SSL;
my $cert = '/path/to/cert.crt';
my ($sock, $s);
if(!($sock = IO::Socket::SSL->new( Listen => 5,
LocalAddr => 'localhost',
LocalPort => 9000,
Proto => 'tcp',
Reuse => 1,
SSL_key_file => $cert,
SSL_cert_file => $cert
)) ) {
warn "unable to create socket: ", &IO::Socket::SSL::errstr, "\n";
exit(0);
}
while (1) {
while(($s = $sock->accept())) {
.
.
.
}
}
While the client is simply:
use strict;
use IO::Socket::SSL;
my $client = new IO::Socket::SSL('localhost:9000');
.
.
.
Does any of this help?
The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon
| 