I use the CApath = directory directive for my client certificates. The client certificates are pointed to by hashed symlinks. Also makes it a lot easier to remove a client certificate if you want to revoke access to your stunnel for that particular certificate.

In other words, is it safe to use together: CAfile=/path/to/my/cacert.pem CApath=/path/to/only/clientcerts

Does not one override other? Do you have your cacert.pem symlinked in your CApath? And lastly as CApath is within chroot, what is the impact if certificates stored in are "stolen" by successfull break-in?

CRL file is *not* 'only certificates signed by my CA', it stands for: do not let any certificates *revoked* by my CA in.

Thanks for the explanation.

Bohdan

On Tue, 22 Feb 2005, Bohdan Linda wrote:

...

I use the CApath = directory directive for my client certificates. The client certificates are pointed to by hashed symlinks. Also makes it a lot easier to remove a client certificate if you want to revoke access to your stunnel for that particular certificate.

In other words, is it safe to use together: CAfile=/path/to/my/cacert.pem CApath=/path/to/only/clientcerts

Yep; except that I only have the CA-certificate chain in cacert.pem.

Does not one override other? Do you have your cacert.pem symlinked in your CApath? And lastly as CApath is within chroot, what is the impact if certificates stored in are "stolen" by successfull break-in?

Q: Does not one override other? A: not that I know of

Q: Do you have your cacert.pem symlinked in your CApath? A: no

Q: And lastly as CApath is within chroot, what is the impact if certificates stored in are "stolen" by successfull break-in? A: The certificates are *public*. So a hacker could allow your clients

access to a client-certificate authenticated service of his/hers own. Far more dangerous would be if your server.pem including its private key would be stolen. An attacker could then impersonate your service thereby sniffing whatever traffic passes his stunnel. There are a number of ways to take care of this risk:

-encrypt the private key of your server.pem; without the passphrase the key is useless to an attacker. There are two disadvantages to this approach: 1. no unattended reboots can be done; no automatic startup of your stunnel service *and* you have to type in the passphrase each time you (re)start the stunnel daemon. I've done this for about a year with an apache+ssl server and got tired of it; 2. if your chroot is compromised it would not be unlikely the attacker installs a sniffer thus voiding the passphrase if you're unlucky -buy an HSM module; they're not that expensive anymore and openssl should interface with them -try to use an USB-PKI token; they're not expensive at all compared to the HSM module and it should be possible to get it working; the private key will be safely stored in there; an attacker can't just copy it; then again; a USB key is more easily removed by a careless person..... -make sure you will *detect* any breakin in a timely fashion and then assume your private key has been compromised;

Jan