Hi Chris: On 2010-09-22, at 4:13 PM, Chris Rider wrote: > For now, I've just copied the CA's public .crt file to a public_html type > directory and downloading on the client ~ from there, depending on whether I > use FireFox or IE, I go into the respective certificates manager and import > the one I downloaded. I've been very deliberate in making sure it actually > gets installed under the root/trusted category, and not some other category. > > I haven't investigated the AIA field... (didn't even know about it) > > Would that be specified when creating the CA's keys? Is that best specified > in my CA's cnf file somewhere? >
Yes - it would. > Barring all else, it seems to me like the browser is hanging up on the fact > that the CA's certificate is self-signed. (??) > Things that would make the browser hang include: CA cert not including basicConstraints: CA=True, or keyUsage not including certSign. and User Certs that DO include either of those values. Also, what could be happening is a mismatch between AKI and SKI values in the CA and Server certs. That's why I requested you to send along a copy of the certs that you are using - the values need to be set correctly, just having one key signed by the other, which happens to be self signed, is not enough. Unless you have extensively edited your openssl.cnf file, you are probably not generating correct CA or end entity certs. Have fun. Patrick. > -Chris > > > Hugo Garza wrote: >> Hi Chris, how are you installing the root CA on the client machines? >> >> In windows once you double click the root certificate you get a message >> dialog box and click the install certificate button. On the following screen >> press next and on the next screen tell it to install the certificate to the >> Trusted Root Certificate Authorities, hit next then finish. You should get a >> Windows dialog warning saying that you are adding a root certificate, and >> you just say yes. >> >> Now the other possible problem is that on the server certificate that you >> created you aren't including the Authority Information Access (AIA) field. >> This is crucial so that your customers only have to install the root CA and >> implicitly trust any certificates signed by the root. >> >> On Wed, Sep 22, 2010 at 2:29 PM, Chris Rider >> <chris.ri...@messagenetsystems.com >> <mailto:chris.ri...@messagenetsystems.com>> wrote: >> >> We have a client/server architecture based product that needs to >> allow SSL communication between our server (CentOS) and various >> clients' web browsers (and additionally, other devices, but that's >> beyond the scope of this post). >> >> We've been able to get SSL working in both of two different ways >> (self-signed certificate & self-signed CA with certificates signed >> by that) -- so that is not the issue. Rather, our whole issue is >> that we don't want the end-users to confronted with a big scary >> browser message that says something akin to "There's a Problem >> With Security! / Allow Exception, etc." If they must install a >> certificate or two, that would be acceptable, though. So I thought >> that creating my own CA to sign certificates with would be a >> solution.... apparently not. I'm now getting browser messages that >> say the certificate's issuer is not trusted!!! Very frustrating. >> >> So, as I said, I've created my own CA (using this link as a guide: >> http://www.g-loaded.eu/2005/11/10/be-your-own-ca/ ), and can sign >> my own certificates without problem. I then install the root >> certificate, followed by a server certificate signed by that CA. >> And, while I can click "allow exception" in the browser to make it >> all work, that is not the desired way. We just want to be able to >> have the end-user install a trusted root certificate and >> everything just work from there. Testing in IE and FireFox nets >> the same big scary warning message, no matter what combination of >> fields I use in the CSR, etc. >> >> We really don't want to go with a third party CA like VeriSign, >> for example -- not so much because of the cost, but we just don't >> want to deal with updating countless remote installations of our >> product whenever the certificate expires. Not to mention the >> support that would be associated with doing that! The other issue >> is that some/most of these installations do not have outside >> internet connectivity with which to query the CA's (for CRL's, or >> whatever). We really need to manage our own certificates, all in >> all.... but without these warning messages. >> >> Is it possible? >> If so, what am I missing? >> >> -- Chris Rider, >> Systems Architect >> MessageNet Systems >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> <mailto:openssl-users@openssl.org> >> Automated List Manager majord...@openssl.org >> <mailto:majord...@openssl.org> >> >> > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
