Am 09.05.2012 17:07, schrieb Bill Cole:
On 9 May 2012, at 9:51, Markus Fritz wrote:
Am 09.05.2012 15:42, schrieb Bill Cole:
On 9 May 2012, at 9:05, Markus Fritz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 09.05.2012 14:32, schrieb Ken Stevenson:
I got only this keys. Can you explain me what exactly you mean with adding chains? And I wonder why this error only occurs in Thunderbird, not in openssl.
Never mind, I don't think my first guess was correct. I wonder if it has to do with the error 27 reported in the verify by openssl. According to the manual, an error 27 means:
"the root CA is not marked as trusted for the specified purpose."
It looks like the certificate is valid cryptographically, but that it wasn't certified for how you're using it.
If I run:
openssl x509 -in ssl.crt -noout -text
The output includes the following:
X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment
Does yours look different?
Mine looks like this:
X509v3 Basic Constraints: CA:FALSE
There's your problem.
If you use a root CA in any X.509 trust chain (even one consisting of a single self-signed certificate) that declares itself to not be legitimate for use as a CA, you will have any signed certificates treated as bogus by any proper X.509v3 implementation. Most tools that create certificates do so with assumptions suited to the external CA model, and set options like the Basic Constraints extension flags that are not fit for a self-signed certificate.
Sorry for my stupid question, but how I can resolve this with a SartSSL signed cert? There I am able to generate a WEB or MIME cert. Thanks for help!
I apologize: I misunderstood which certificate you were looking at with openssl.
Having re-read the whole thread and after reading at the pastebin items you posted, I believe the problem you are having is a result of the fact that your certificate is not directly signed by the StartSSL root CA, but is "chained" with an intermediate certificate. This is a common situation, and it means that a client needs some way to get a copy of the intermediate certificate that was used to sign the server certificate. The normal way to do that is to put all of the certificates in the chain into the certificate file so that the server using that file sends them all to clients. This is documented at http://wiki.dovecot.org/SSL/DovecotConfiguration#Chained_SSL_certificates
The intermediate certificate that you need can be retrieved from http://aia.startssl.com/certs/sub.class1.server.ca.crt in DER format. You need to convert that to PEM format ('openssl x509 -inform DER < sub.class1.server.ca.crt' will put out the certificate in PEM form) and add it to your certificate file (based on your pastebin: /etc/ssl/opsys/startssl/ssl.crt). You may also want to add the actual StartSSL root certificate as well, but that is unlikely to be necessary.
A failure of a certificate to verify in some clients and not others or for some users and not others is usually do to a server not including intermediate CA certificates. Some clients and users may have a store of certificates that includes a widely-used intermediate CA cert provide by some other server in the past, so they will be able to verify the chain, while others won't have the cert and may have no persistent cert store.
Thanks! That might help, yes I got the sub.class1.server.ca.pem file. How I include this to my ssl.crt file now? This cert terms are so confusing and I recognize that I am still standing at the beginning. But it's really interesting. Thanks for help!
-- Markus Fritz Administration