ssl

For my own sites I use SSL certificates signed by my own CA.

The CA certificate needs to be imported to the machines where I use the websites and for Mac OSX it needs to go into the system keychain - not the users keychain.

Importing via Keychain Access sometimes fails with cryptic error codes.

Here's how to do it via the command line:

sudo security import  -k /Library/Keychains/System.keychain

I delegate my domains OpenID logins to myopenid.com - but I was having issues getting SSL certificate based login to work in safari.

There is one extra step that I seem to need to get this to work properly ...

Instead of using a self-signed certificate with glassfish (see Creating new SSL keys with keytool for glassfish) - we want to use one that is signed by a certificate authority.

Based on http://blogs.sun.com/enterprisetechtips/entry/using_ssl_with_glassfish_v2

For this entire post - the keystore.jks file is the one found in the glassfish domain config - e.g. glassfish/domains/domain1/config/keystore.jks

I've been using self-signed certificates for a while - but - that means getting the users to approve them each time they change. Instead - lets generate a Certificate Authority (CA) certificate with a reasonably long life - get them to install that and then new certificates signed with that will be valid for them.

We will install a CA area on /etc/ssl/ca and then create a certificate signed with this.

Setup
We're going to use the script CA.pl which on debian is installed on /usr/lib/ssl/misc. But - we need to make some changes

I needed to generate a new certificate for glassfish's admin pages.

Instead of using the normal OpenSSL self-signed certificate it was easier just to use the java keystore keytool

keytool -genkey -keyalg RSA -alias
<alias_referred_to_in_glassfish>
-keystore glassfish/domains/domain1/config/keystore.jks
-storepass changeit

Note the -keyalg RSA - keytool by default uses DSA and firefox 3.0 will not accept this even with an added security exception.

UPDATE - progress - see end of article

I have an openssl self-signed certificate for some websites. These are based on an openssl RSA key. I can use them successfully as client keys - but - it seems that glassfish (perhaps all others - I don't know) need the key in the keystore as well as the certificate.

So - I have an RSA key file and a PEM certificate file.

I use a plugin to Aperture to send mail to gmail. It was failing due to a

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path
building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target

The plugin author (plugin home page) found the following utility:

http://blogs.sun.com/andreas/entry/no_more_unable_to_find

For more info on the debian security announcement see:

http://lists.debian.org/debian-security-announce/2008/msg00152.html

Server keys for this host have been updated - any ssh users may well need to remove the old ones from their .known_hosts file (or equivalent). Just to let them know that the keys are changed and intentionally so.

I was experiencing odd things integrating to google maps - although I have both an API key for http and https - only https was working.

It turns out that the setting of the apache environment variable SERVER_PORT was always 443 irrespective of whether I was using http/80 or https/443 from the client.

I have several NameVirtualHosts on different IPs.

In apache2.conf:

There are several reasons you may need to add a self-signed https ssl certificate to your local java keystore.

For me - its so that maven can access DAV shares for repository deployment.

Cargo culted direct from the exim site.

openssl req -x509 -newkey rsa:1024 -keyout /etc/exim4/exim.key -out /etc/exim4/exim.crt -days 9999 -nodes

The really important bit is that the common name (CN) field must be the server name (at least so it seems to be for me)

Don't forget - if your pop3 and imap certificates also expire at the same time to renew them to.

Mail.app wouldn't stop asking about the certificates.

So:

1. Remove any instances of them from Keychain Access
2. Try to get mail - when told about the certificate choose View certificate and drag the icon to the desktop
3. Don't add the cert to your login keychain - drag it to the X509Anchors chain instead.
4. Mark it as always trusted (after all - you trust yourself don't you?)
5. Repeat 2. - 4. for sending mail.

Bingo! Well - works4me at least.

I was using courier-imap and courier-pop until today. I've just installed the -ssl versions of both.

At install they both create a certificate for localhost based in New York. This doesn't work unless it really is localhost.

In /etc/courier there are imapd.pem, imapd.cnf, pop3d.pem and pop3d.cnf

1. Delete the .pem files
2. Edit the .cnf files - make sure that you set CN to be the hostname or the mail server
3. Run mkimapdcert
4. Run mkpop3dcert
5. Restart the services

I left the non-ssl IMAP running but only for 127.0.0.1 for squirrel

There are two kinds of certificates available - self-certified (free - but people will have to either accept the certificate or manually install it) or paid for (you buy it from a Certificate Authority and as long as that CA is a common one then it will just work in most browsers).

First you will need a private key:

cd /etc/ssl
openssl genrsa -des3 -out private/your.domain.tld.key 2048

Drop the -des3 if you don't want a password (this will allow auto-startup of apache - but is much much less secure). Note - if you are going to purchase a certificate - check how many bits the provider wants you to use.

Just a note to self - to generate a new certificate

openssl req -new -key /etc/ssl/private/keyfile -x509 -days nnn -out /etc/apache2/ssl/certfile