Someone just sent me a perl script to generate the openssl.cnf file to include subjectAltNames etc...
http://wiki.cacert.org/wiki/VhostTaskForce
Scroll to the bottom of the page...
Duane, I downloaded your code and a quick check shows you do use openssl to emit the certificate (the configuration file is not available in thoses sources).
From the above discussion, I suppose you use the (non default because of the security risks) option "copy_extensions = copy" of Openssl to allow extension from the request to be copied to the cert ?
But this means you can't really control what extensions will in the emitted cert.
With that option, you can avoid some of the most dangerous effects by forcing the value of some extensions ; here you explicitly force Basic Constraint to be present and have the value CA=False (even if it break the DER rules, but anyway CA can't allow themselves to be correct on that point), but that still leaves a door open for anything to happen if it was not foreseen.
Another point, how much review by security experts on your code did you have until now ?
You're using a bunch of technologies here, php, shell running executable, sql requests you dynamically construct and that might be linked to some of the input data, that are really hard to get right and not introduce security failures. You probably don't have the budget to pay for a full review, but even a cursory review can be useful. And you can make some publicity about the fact your code is available, and that you'd welcome any help to make it as secure as possible.
Moreover, it's possible I got it wrong somewhere, but what I see seems to imply the private key of the CA is directly used from the web server.
This is a bad security practice. You *need* to have the private key on a separate machine, so that if your webserver gets hacked, which is an event there is no way to fully protect against, he still needs then to hack the other machine to get your key.
And this even if the key is in an hardware module, because it can be some time before you notice your webserver has a problem, so let's make whatever we can so we have a chance to stop the attacker before he successfully gets a lot of things signed. This is a special case where security by obscurity about how the two machines communicate between each other can make sense.
There is another point that is really a bad idea by itself, but that the previous points makes even worse, it's the fact your root CA directly signs the certificates.
You MUST use an intermediate CA. And IMO you must use an off-line root CA, that is a CA that is physically unplugged, and gets used very rarely. That way if the worst happens and your key is compromised, it's only the on-line CA. You can get your off-line CA out of it's vault to sign a CRL that revokes it, emit new certificates for all you legitimate clients, and go on.
It's also a good idea to regularly change the intermediate CA. You keep the crl size under control, and in case of compromise only some of the certs are not concerned (even if older intermediate CA will stay on-line to emit crl, but maybe you can lower the frequency of those crl and use an airwall : http://en.wiktionary.org/wiki/Airwall ).
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
