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’
(http://en.opensuse.org/Apache_SSL_CA_Generator). 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
ken_yap;1904396 Wrote:
> 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.
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
tsu2;1904904 Wrote:
> 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
>
> *.domain.com
>
That would be an interesting one… But don’t browsers always check
against the fqdn, meaning the exact domain name?
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 hosts, different 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.
ken_yap;1904922 Wrote:
> No, that’s the point of the wildcard. The match will be:
>
> site.domain.com : *.domain.com
>
> where : means compare. So various FQDNs will match the same
> certificate.
>
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…)? ’
Magic31;1904929 Wrote:
> 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.
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.
