hi Jack,I just wanted to add that though wildcards in DBs may be very practical, but (as in most such cases) reduces the security of a certificate for the client side.
On Wed, Jan 07, 2004 at 12:39:37AM -0800, [EMAIL PROTECTED] wrote:
Hmmm ... I see. The server certificate's CN is compared to the server's name as it is provided to the client. This is unlike the behavior of kerberos, which performs a reverse lookup of the server's IP to locate it's principal. I suppose this solves my problem creating unique DNs for each of my services. It poses, however, another problem. There are potentially many names by which my server can be accessed - I would rather not list them all in a certificate. Because I've used a wildcard in my DNS configuration, there are actually an infinite number of names by which my server can be accessed: a.server, aa.server, aaa.server,
some clients may accept wildcard in server certificate CN, "*.example.com"
[...]I just did a test with Mozilla 1.5 on NT. There if I enter "https://smtp"; and the default domain from the IP-Configuration is "example.com" it implicitly tries "https://smtp.example.com"; and accepts the Certificate whith DN "smtp.example.com". But (as Vadim said) this is something which has to be implemented on the client side and might not work with IE, Opera or even another version of Mozilla...
is a proper prefix of the CN, and the two don't match: "example.com" is appended to "smtp", but SSL unsuccessfully compares only "smtp" to the server's CN, "smtp.example.com".
It's up to a client to implement such a comparation rule and it's unlikely
widely used.
I agree with Vadim. Using reverse-lookup on the client side would completely render the Server-Certificate useless, since everyone who can fumble around with DNS can transform the IP-Adress into any name he likes. The danger of fumbling around with DNS is the reason why Server-Certs are needed in the first place...Can openSSL be configured to compare the certificate's CN to a reverse lookup of the server's IP?
OpenSSL is an open-source tool that you can make doing something you'd like. At some point the user should be convinced an OpenSSL-liked product is doing the right thing and/or provided with a description what exactly it is doing.
I'm curious what's the use of data from (unsigned?) reverse zone here
If the client wants to connect "secure.example.org" the server must present a Certificate for this name and not for "evil.example.org" or "192.168.1.1", even if secure.example.org is an alias for evil.example.org and its IP is 192.168.1.1. Sad but true. ;)
[...]
Kind regards, Ted ;)
-- PGP Version: 2.6.3i Public Key Information Download complete Key from ftp://ftp.convey.de/ted/tedkey.asc Key fingerprint = 26 A9 0C 25 60 15 2C B2 D0 F3 A2 31 3D 35 F3 95
smime.p7s
Description: S/MIME Cryptographic Signature
