Was wondering if there is a good howto on how to setup or recreate a Certificate Authority. Also generating new certificates and where to place them so Apache will use it (maybe even how to let Apache use different certificates depending on which link has been accessed by the user).
Doing this in openSUSE is still a bit vague for me…
I’ve found an older script here Apache SSL CA Generator - SUSE 10.1. Seems it should work in 11.x but it would be nice to be able to do this using YaST’s CA tool.
SLES handles the CA and certificate generation automatically during install. Wondering how that is done. anyone know if this is based on the same Apache SSL CA Generator script?
There’s an app called tinyca2 which will give you a nice front end to the openssl ops required. Otherwise the documentation that comes with openssl explains everything.
Remember that the browser will do a reverse lookup on the IP address and compare the result with the name in the cert. So you will need the same name in all the certs. If you run virtual hosts then you will need multiple IP addresses or a wildcard cert, otherwise it will fail that check.
BTW, don’t hold me to this as I haven’t thought it out fully yet, but I think you’ll find that to use different certs for different parts of a website you’ll need virtual hosts, as a SSL connection secures a (virtual) site, not a single transfer. And of course, if your certs are self-signed, you’ll have these exception warnings from Firefox for each cert.
@ken_yap: thanks, will be looking into that one.
Also FYI, there is a YaST module that should also make the CA setup easy (yast2-ca-management). The thing is that if you have to setup a CA from scratch, it’s nice to have a step by step guide telling you a bit more about which things to look out for.
The certificate chain can be a tricky thing to handle, especially if the CA is not setup correctly.
@Monex: Very nice howto you’ve got there! I’ll be having a good read through that too.
If I can make a good translation of the steps mentioned using the YaST CA tool, I’ll try to put up a guide for it. Seems this should have been documented already… but can’t seem to find any comprehensive info on the tool… just some loose notes. Might say more about my finding skills though
Although that is normally the case, when supported (usually by the client app and most current browsers do) there is the wildcard certificate where the CN is something like
where : means compare. So various FQDNs will match the same certificate.
However, that’s all well if you want to use the certificate for multiple distinct hosts in the domain where distinct means different IP. (Doesn’t imply different physical hosts, multiple IPs can be arranged via IP aliases, provided the addresses are available.) But as I understand it, Magic31 wants the other way, to have different areas covered by different certs. That could be costly, if that’s what you want and you use commercial certs. If using self-signed certs, you’d have to overcome the browser’s caution. I think this can be done by importing the certs ahead of time into the browser.
Thanks, …I never thought of that, as to me the wild card seems to break one of the reasons for using certificates: verifying the host is who it says it is. setting the CN to the fqdn seems more secure… But I always find this part more a false sense of security rather than an air tight one.
… But as I understand it, Magic31 wants the other way, to have different areas covered by different certs. That could be costly, if that’s what you want and you use commercial certs. If using self-signed certs, you’d have to overcome the browser’s caution. I think this can be done by importing the certs ahead of time into the browser.
Right on target Ken_yap! For IE it’s quite easy to instruct people to import the certificate and be done with the warning message.
For Firefox (v3) it’s even easier as they only have to indicate an exception when first accessing the site.
I’ll be giving all the tips given here a first try on Monday… will let you know how that goes.
And again, I want to see how easy the YaST CA tool makes this.
I don’t mind learning the console commands… but it’s always that look I get when trying to share that knowledge with others… the look says it all… ’ ain’t there a nice little clicky GUI I can click on and it does this for me…(it’s a kind of magic…)? ’
Well in this case you are trusting the entire domain rather than one host. The danger would be if someone in-house obtained the private part of the cert and then set up an unauthorised host within the domain that would pass the comparison. The usual sysadmin precautions would be used to prevent this.
Ken,
your last post (preceding this one) is the right take…
Assuming the Web SysAdmin properly secures his certificates, the Client should feel confident he’s connecting to a valid, authorized resource even when it’s a wildcard certificate.
This assumes of course that the Client is configured properly to trust the CA. Note that when setting up a CA properly, the issued certificates are <not> self-generated types which can be created on any machine, they’re generated with full information about the authorization tree.
Don’t confuse this with the common “import the web certificate from an untrusted website” procedure, that’s intended only to be a one-shot procedure that’s rife with potential pitfalls.
Instead, the Client should be configured with the CA’s certificate (not from the resource/website) so that based on this one certificate (trusting the CA) any certificates issued by the CA are trusted.
Also, if you do decide to setup your own CA and want to avoid special distribution and configuration of your CA’s certificates to all clients, you can pay an existing trusted CA to issue a special “Intermediate CA” to your CA so that you become part of the chain of trusted CAs.
