Date: Fri, 11 Jan 2002 11:18:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: Dominic Mitchell <dom@semantico.com>, freebsd-hackers@FreeBSD.org Subject: Re: [OT] OpenSSL, certification chains and Exim Message-ID: <3C3F3A93.C1ECF9B0@mindspring.com> References: <52230.1010758680@axl.seasidesoftware.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Sheldon Hearn wrote: > On 11 Jan 2002 13:58:30 GMT, Dominic Mitchell wrote: > > I'm not an OpenSSL wizard, but this sounds like either a self-signed > > certificate, or a root CA which isn't in Outlook's trusted list of > > root CA's. > > In Outlook's case (although the problem exists with some Netscape > messaging client and a recent Eudora as well), the self-signed > certificate has been installed into the Trusted Root Certification > Authorities store. > > That said, I'd be more than happy to hear that this is just a Wintendo > problem and nothing to do with the Unix components. The murmurings I've > read from the Wintendo community aren't convincing. > > Also, I'm loath to continue discussing the issue on this list, since > it's off-topic. I'd rather solicit advice sent in private. I'm continuing it on this list. 8-). The reason is that it's always nice to capture in the archives the domain specific knowledge of how to get FreeBSD to interoperate with Windows, etc.. I'm going to "dumb this down"; not the the point of uselessness, but to the point that it is understandable by a layman, so anyone else out there who us clued enough to take issue with my explanation, but "too clued to answer the question that was asked", go easy on me! 8-) I believe the problem is that the certificate used to sign the server certificate was the installed, rather than the authority certificate. The way certificates work is that they are signed with the private key of a signing authority, providing a public key for verification of the signature. The way this operates is that you assume a trusted public key from a trausted authority. The trusted authority signs a certificate containing a public key of another p[rivate key, and, because you trust the original public key, you verify that the certificate is valid, and thus trust the public key in the signed certificate; so you get: [ trusted public key A ] | V [ trusted private key A ] | V [ certificate containing public key B signed with private key A ] | V [ trusted-by-chain private key B ] | V . . . [ certificate containing public key N signed with private key (N-1) ] | V [ trusted-by-chain private key N ] In addition, the signing certificate contains information as to whether or not it is capable of signing signing certificates. When you send a chain, basically, you send a certificate (usually a "leaf" certificate -- one that is not permitted to sign others), signed with a signing certificate (and the signing certificate public key), all the way to the "root" signing certificate. A certificate is considered a "root" certificate if it is installed in the software as "trusted". Note: Some software insists the "root" certificates be self-signed, so it's not possible to set up an intermediate certificate as a "root" certificate merely by installing it as one, unless it meets this criteria as well; in general, software does this to be a pain in the arse to use with "unapproved" certificate authorities, ones that have not been factory preinstalled as allowed exceptions (you will obviously never see even certificates 4 down from Thawte or VeriSign's certificate servers, even if you are The Pope). So the problem is that the installed certificate is the same as the authoritative (implied trust) certificate, instead of one that was signed by the private key it contains. In other words, you should be able to fix it by creating a signing certificate, trustung the signing certificate, and signing a leaf certficate, which the software then trusts because of implicit trust of the signing certficate. This might be all you have to do. This is (potentially) further complicated by: 1) Your software is throwing a hissy fit intentionally, because the vendor has a contract with a certificate vendor that requires it to throw a hissy fit, unless the authoritative certificate is self-signed, or from a contracted vendor (VeriSign sometimes does things like this). 2) Your verification certificate is *not* a leaf certificate; sometimes software will enforce this, as well. So my advise is: A) Self-sign a signing certficate B) Install it as authoritative in the software C) Sign a leaf certificate (a *non-signing* certificate) with the signing certificate, and use that one in your server software D) Verify that every certificate between the leaf certificate and the authoritative certificate is being sent when the leaf certificate is requested (ther is a big-arse MIME type for doing certificate chains like this). Step (D) should not be necessary, if you are one step away from the authoritative certificate. RFC 1423 is a good starting point, and there are a lot of nice books on the subject, but I don't think any of them are less than ~300 pages. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C3F3A93.C1ECF9B0>