Hello,
the error is still present: May 8 19:47:18 opsys dovecot: imap-login: Disconnected (no auth attempts): rip=82.113.119.140, lip=78.46.216.126
Whenever I start a session with openssl to STARTTTL (Server: mail.opsys.de) the handshake is successfull. Also I am able to login to my account via 1 login. In Thunderbird port 993 for SSL/TLS works correct, only STARTTLS on port 143 isn't working properly. The cert is Class 1 and signed by StartCom Ltd.. Dovecot.conf (for viewable reasons of this mail pasted): http://pastie.org/private/bmrymyuo16ohzxdahf0nq And here openssl output: http://pastie.org/private/3rpgll2s7hblev9ozpcq8w Note the 'Verify return code: 21 (unable to verify the first certificate)' in the output...
Thanks for helping, I am working on this problem since 3 days.
Kind regards
Markus Fritz
I'm just learning about this, but I was able to get it working recently. Also I haven't read your earlier posts.
Did you receive intermediate certificates from StartCom? When I got my certificate, I had to concatenate together the contents of the domain_name.crt file and the gd_bundle.crt file. That concatenated file is the one I specify for ssl_cert_file. It has 4 certificates in it. I ask because when I run the openssl command, my certificate chain has 4 sections where yours only has one.
Does your ssl.cert have the intermediate certificates in it?
On 2012-05-08 14:17, Markus Fritz wrote:
Hello,
the error is still present: May 8 19:47:18 opsys dovecot: imap-login: Disconnected (no auth attempts): rip=82.113.119.140, lip=78.46.216.126
Whenever I start a session with openssl to STARTTTL (Server: mail.opsys.de) the handshake is successfull. Also I am able to login to my account via 1 login. In Thunderbird port 993 for SSL/TLS works correct, only STARTTLS on port 143 isn't working properly. The cert is Class 1 and signed by StartCom Ltd.. Dovecot.conf (for viewable reasons of this mail pasted): http://pastie.org/private/bmrymyuo16ohzxdahf0nq And here openssl output: http://pastie.org/private/3rpgll2s7hblev9ozpcq8w Note the 'Verify return code: 21 (unable to verify the first certificate)' in the output...
Thanks for helping, I am working on this problem since 3 days.
Kind regards
Markus Fritz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm just learning about this, but I was able to get it working recently. Also I haven't read your earlier posts.
Did you receive intermediate certificates from StartCom? When I got my certificate, I had to concatenate together the contents of the domain_name.crt file and the gd_bundle.crt file. That concatenated file is the one I specify for ssl_cert_file. It has 4 certificates in it. I ask because when I run the openssl command, my certificate chain has 4
Am 08.05.2012 20:58, schrieb Ken Stevenson: sections where yours only has one.
Does your ssl.cert have the intermediate certificates in it?
On 2012-05-08 14:17, Markus Fritz wrote:
Hello,
the error is still present: May 8 19:47:18 opsys dovecot: imap-login: Disconnected (no auth attempts): rip=82.113.119.140, lip=78.46.216.126
Whenever I start a session with openssl to STARTTTL (Server: mail.opsys.de) the handshake is successfull. Also I am able to login to my account via 1 login. In Thunderbird port 993 for SSL/TLS works correct, only STARTTLS on port 143 isn't working properly. The cert is Class 1 and signed by StartCom Ltd.. Dovecot.conf (for viewable reasons of this mail pasted): http://pastie.org/private/bmrymyuo16ohzxdahf0nq And here openssl output: http://pastie.org/private/3rpgll2s7hblev9ozpcq8w Note the 'Verify return code: 21 (unable to verify the first certificate)' in the output...
Thanks for helping, I am working on this problem since 3 days.
Kind regards
Markus Fritz
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.
Markus Fritz Administration
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPqjmiAAoJEINBXoxEgR1s+moIAJMfHRtIRC1JrBno8bbRxVuR Yc1xx196N80DFzzMD9+G77SXO0gJqmbzD5KjFwllt3JxtTr3XFIjKhutW8mEcLh2 EU65CH9TCWByXkzQSoFGTGKwdX7OKG4doSm7MZuQtpV6jVmZrIOs6GEFD+cApWy/ I1aWfKqK7b6S8bYRqw57hlNsuYxv6kB4w1t+IC9wMHbx5ULNWmZwxL2O/TWBnv2c qEbu8bkHIhebNq9NdEGGWZnAd36Kv3Ji231HjgD/WhQjcnF2LNzHIQ4B11xRiOBC LzYN8RLi4iOuloSHLlylNmob/bgAwxL8AdESo5n+1SwYDBcRy1CllEbD+QYSUoc= =Cjg6 -----END PGP SIGNATURE-----
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?
-----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 X509v3 Key Usage: Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Server Authentication
Markus Fritz Administration
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPqmuQAAoJEINBXoxEgR1sshwIALPRc0ozkTms2z9q+wLo8nP4 ELA7OsIUYiRUbhO1WOvfUQ+Ltssw5WcmvDQdpiAEZBL92s3hLvGqiJxc4TjoF3Fd lfar4OIQ/G2GMgzA9QeJu/EVMks29031RifSo2zkXnmTJMoTVAtsnRMc3UwIOTPV 0yDAXMZN7Ph4t5TbjJRk6Dox2PZj9qsixsOXb82ErE9TyaKT/p+Qdk2U/gvKWMUM Himz4q6bWIpc5D+h1KKes27+HIHPWjFLE2OPKfF58vw1ws1dmYvwM14v3RRW9e1X UYBZXcv5dIJHNXhkANgY/reWQjl3QU5JIalyU4S8MaF1OTr4Gr4SzsBBzY5eCd0= =j6Vx -----END PGP SIGNATURE-----
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.
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!
-- Markus Fritz Administration
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.
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
On 2012-05-09 22:48, Markus Fritz wrote:
Thanks! That might help, yes I got the sub.class1.server.ca.pem file. How I include this to my ssl.crt file now?
Just append the intermediate CA certificate in the same file AFTER your own certificate. As in:
# cat sub.class1.server.ca.pem >> ssl.crt
As a result you should have a file ssl.crt which consists of the following:
-----BEGIN CERTIFICATE----- [several lines of your own certificate] -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- [several lines of the intermediary certificate] -----END CERTIFICATE-----
...and nothing else.
-- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/
Am 09.05.2012 18:50, schrieb Janne Snabb:
On 2012-05-09 22:48, Markus Fritz wrote:
Thanks! That might help, yes I got the sub.class1.server.ca.pem file. How I include this to my ssl.crt file now? Just append the intermediate CA certificate in the same file AFTER your own certificate. As in:
# cat sub.class1.server.ca.pem >> ssl.crt
As a result you should have a file ssl.crt which consists of the following:
-----BEGIN CERTIFICATE----- [several lines of your own certificate] -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- [several lines of the intermediary certificate] -----END CERTIFICATE-----
...and nothing else.
Thanks, I've done that. But it didn't help. Thunderbird still has the error 'TLS not aviable due tempoary reason'. The key still has (when I do openssl x509 -in ssl.crt -noout -text) X509v3 Basic Constraints: CA:FALSE
Remember: IMAP with SSL/TLS on port 993 is running well. STARTTLS on port 143 not.
-- Markus Fritz Administration
On 2012-05-10 03:29, Markus Fritz wrote:
The key still has (when I do openssl x509 -in ssl.crt -noout -text) X509v3 Basic Constraints: CA:FALSE
I believe this only means that you can not use the certificate as a CA certificate and issue sub-certificates of that certificate. IMHO this is not an issue, it is how it should be. The problem is somewhere else.
-- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/
On 2012-05-08 14:17, Markus Fritz wrote:
Hello,
the error is still present: May 8 19:47:18 opsys dovecot: imap-login: Disconnected (no auth attempts): rip=82.113.119.140, lip=78.46.216.126
Whenever I start a session with openssl to STARTTTL (Server: mail.opsys.de) the handshake is successfull. Also I am able to login to my account via 1 login. In Thunderbird port 993 for SSL/TLS works correct, only STARTTLS on port 143 isn't working properly. The cert is Class 1 and signed by StartCom Ltd.. Dovecot.conf (for viewable reasons of this mail pasted): http://pastie.org/private/bmrymyuo16ohzxdahf0nq And here openssl output: http://pastie.org/private/3rpgll2s7hblev9ozpcq8w Note the 'Verify return code: 21 (unable to verify the first certificate)' in the output...
Thanks for helping, I am working on this problem since 3 days.
Kind regards
Markus Fritz
How about this:
Note: If you receive an error that looks like:
454 TLS not available due to temporary reason', Port: 25, Secure(SSL): Yes, Server Error: 455, Error Number: 0x800CCC7F
or anything similar, it is because your Norton AntiVirus Email Scanning or other Anti-Virus software is scanning your outgoing email. Shut off the 'Scan outgoing Email' option and it should work.
It came from here:
https://cs.stanford.edu/computing-guide/email/client-settings
Am 09.05.2012 22:40, schrieb Ken Stevenson:
On 2012-05-08 14:17, Markus Fritz wrote:
Hello,
the error is still present: May 8 19:47:18 opsys dovecot: imap-login: Disconnected (no auth attempts): rip=82.113.119.140, lip=78.46.216.126
Whenever I start a session with openssl to STARTTTL (Server: mail.opsys.de) the handshake is successfull. Also I am able to login to my account via 1 login. In Thunderbird port 993 for SSL/TLS works correct, only STARTTLS on port 143 isn't working properly. The cert is Class 1 and signed by StartCom Ltd.. Dovecot.conf (for viewable reasons of this mail pasted): http://pastie.org/private/bmrymyuo16ohzxdahf0nq And here openssl output: http://pastie.org/private/3rpgll2s7hblev9ozpcq8w Note the 'Verify return code: 21 (unable to verify the first certificate)' in the output...
Thanks for helping, I am working on this problem since 3 days.
Kind regards
Markus Fritz
How about this:
Note: If you receive an error that looks like:
454 TLS not available due to temporary reason', Port: 25, Secure(SSL): Yes, Server Error: 455, Error Number: 0x800CCC7F
or anything similar, it is because your Norton AntiVirus Email Scanning or other Anti-Virus software is scanning your outgoing email. Shut off the 'Scan outgoing Email' option and it should work.
It came from here:
https://cs.stanford.edu/computing-guide/email/client-settings Sorry but: oh my god Thanks, really. Days of working and this simple resolution. I am running Avira and EMail scanning was turned on. Now it's working perfectly. That made my day.
-- Markus Fritz Administration
participants (4)
-
Bill Cole
-
Janne Snabb
-
Ken Stevenson
-
Markus Fritz