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