Re: Self-signed CA problem for internal web application
Sure.. but please excuse me as this is the first time posting on this forum ~ post in plain text or does this system support attached files? Patrick Patterson wrote: Hi Chris: Can you post the certificates in question? My guess is that you don't have the various extensions set according to the PKIX standards that the Browsers are expecting. Thanks. Patrick. On 2010-09-22, at 2:57 PM, Chris Rider 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 chris.ri...@messagenetsystems.com __ 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Self-signed CA problem for internal web application
I think we're on to something here... thank you for your time and
attention, btw!
I still can't see anything about the AIA thing, but I took another go at
the basicConstraints and keyUsage, and seem to have slightly better
results. I changed basicConstraints to True (it was FALSE by default),
so that makes sense. I also just tacked on certSign to the end of the
keyUsage string. Now, when I generate the keys and install the CA's
certificate on the client, even IE will automatically detect/install as
a trusted root... which it wasn't before. So I think we're onto
something with my CA.
But now, when I go to sign the server certificate using my CA, I am
getting the following errors: (using the exact same process -- scripted
-- as before, so the only thing changed is the CA config file / CA keys)
Error Loading extension section usr_cert
14488:error:02001002:system library:fopen:No such file or
directory:bss_file.c:122:fopen('/etc/pki_MessageNet/CA/index.txt.attr','rb')
14488:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:125:
14488:error:0E078072:configuration file routines:DEF_LOAD:no such
file:conf_def.c:197:
14488:error:0E06D06C:configuration file routines:NCONF_get_string:no
value:conf_lib.c:329:group=CA_default name=email_in_dn
14488:error:2206E068:X509 V3 routines:X509V3_get_value_bool:invalid
boolean string:v3_utl.c:229:section:,name:CA,value:True
14488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
extension:v3_conf.c:93:name=basicConstraints, value=CA:True
What is the best way to include my file contents for you? (worried about
posting something a mile long)
Patrick Patterson wrote:
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
Re: Self-signed CA problem for internal web application
Sorry, I think I should make clear that I'm using two different
setups... one for the CA and another for the end user certificate.
For example, my CA is in /etc/pki_MessageNet/CA while my end-user is in
/etc/pki_MessageNet/tls --- so when I generate my CA keys, it has its
own config file / scope... and when I generate my end user CSR, it has
its own config file / scope. I am, however, granting my CSR from within
the scope of my CA and its configuration. In other words, I'm
replicating a real world type situation -- or that is the hope!
Chris Rider wrote:
I think we're on to something here... thank you for your time and
attention, btw!
I still can't see anything about the AIA thing, but I took another go
at the basicConstraints and keyUsage, and seem to have slightly better
results. I changed basicConstraints to True (it was FALSE by default),
so that makes sense. I also just tacked on certSign to the end of the
keyUsage string. Now, when I generate the keys and install the CA's
certificate on the client, even IE will automatically detect/install
as a trusted root... which it wasn't before. So I think we're onto
something with my CA.
But now, when I go to sign the server certificate using my CA, I am
getting the following errors: (using the exact same process --
scripted -- as before, so the only thing changed is the CA config file
/ CA keys)
Error Loading extension section usr_cert
14488:error:02001002:system library:fopen:No such file or
directory:bss_file.c:122:fopen('/etc/pki_MessageNet/CA/index.txt.attr','rb')
14488:error:2006D080:BIO routines:BIO_new_file:no such
file:bss_file.c:125:
14488:error:0E078072:configuration file routines:DEF_LOAD:no such
file:conf_def.c:197:
14488:error:0E06D06C:configuration file routines:NCONF_get_string:no
value:conf_lib.c:329:group=CA_default name=email_in_dn
14488:error:2206E068:X509 V3 routines:X509V3_get_value_bool:invalid
boolean string:v3_utl.c:229:section:,name:CA,value:True
14488:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
extension:v3_conf.c:93:name=basicConstraints, value=CA:True
What is the best way to include my file contents for you? (worried
about posting something a mile long)
Patrick Patterson wrote:
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) --
Re: Self-signed CA problem for internal web application
Thanks for the suggestion, but I've already tried that, more or less My web server config already has that mime type configured, and the client is capable of recognizing the properly served filetype. I've tried installing certificates through IE's wizard automatically in such a way... as well as manually in it and other browsers (downloading certificate and importing). My primary skills are that of webmaster (using that word should tell how long I've been in that game! grin), so I am aware of how much the browsers vary in doing things... which is why I tried every way of installing in every browser I have. I agree with you about the latest versions of MSIE and that stupid wizard they now use! I'm pretty sure it something in my generating keys, rather than client issues. John R Pierce wrote: On 09/22/10 11:57 AM, Chris Rider 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. take your selfsigned CA public certificate, name it something.cer, and place it on a web server, making sure the webserver understands that .cer is mime type application/x-x509-ca-cert give your clients the link to that .CER ... they have to accept it and add it to their trusted root certificate storage, the specifics of doing this vary by web browser (current versions of MSIE have made this harder than it should be) once that .cer is installed in the browsers trusted root authorities, then anything signed by that CA will be accepted. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Self-signed CA problem for internal web application
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 chris.ri...@messagenetsystems.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Self-signed CA problem for internal web application
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Self-signed CA problem for internal web application
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 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Self-signed CA problem for internal web application
Hi Chris: Can you post the certificates in question? My guess is that you don't have the various extensions set according to the PKIX standards that the Browsers are expecting. Thanks. Patrick. On 2010-09-22, at 2:57 PM, Chris Rider 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 chris.ri...@messagenetsystems.com __ 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Self-signed CA problem for internal web application
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? Barring all else, it seems to me like the browser is hanging up on the fact that the CA's certificate is self-signed. (??) -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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Self-signed CA problem for internal web application
On 09/22/10 11:57 AM, Chris Rider 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. take your selfsigned CA public certificate, name it something.cer, and place it on a web server, making sure the webserver understands that .cer is mime type application/x-x509-ca-cert give your clients the link to that .CER ... they have to accept it and add it to their trusted root certificate storage, the specifics of doing this vary by web browser (current versions of MSIE have made this harder than it should be) once that .cer is installed in the browsers trusted root authorities, then anything signed by that CA will be accepted. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Self-signed CA problem for internal web application
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
