Do you have a question? Post it now! No Registration Necessary. Now with pictures!
September 11, 2006, 12:30 pm
rate this thread
My first post to this group, pls bear with me. I'm working with Java
and various network services, some of which are secured with SSL, both
with self-signed and CA signed certificates.
It surprises me that SSL certificates signed by CAs are (fully
qualified) hostname based and not wildcard based, i.e. when I request a
signed certficate I have to state the full name. If I need to secure
another host, I have to generate a new request and have that hostname
signed for as well. This can't be other than a commercially driven
procedure. Surely, if Verisign authenticates company ACNE Inc. and sign
a certificate for foo.acne.com, then what it really /could/ do is sign
*.acne.com and this certificate should be accepted by all clients that
trust Verisign. I guess all SSL APIs are programmed to perform a pure
equality check between DNS name and the certificate's common name, but
what it /should/ do is compare the top-domain/sub-domain (acne.com)
part of the domain name and compare it to the certificate's common name
(which should be acne.com and not having to be foo.acne.com,
Why isn't it so? Is it purely commercial, or does it provide any
stronger security this hostname driven signing model?
Any input would be much appreciated.
Re: SSL CA signed certficates
Wildcard certificates are available (or have been, at least), but
at a price significantly higher than that of fully qualified certificates.
be used. So, it's pretty much a commercial driver, as you state.
However, with the current proxy technology, what would be the driver
for several SSL-enabled hosts on a single domain? Just do the namespace
division in URL path instead of using several host names.
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)