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.
