Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42) - sni

2022-10-11 Thread Jochen Bern 

On 11.10.22 17:46, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:

ok according to
https://www.openssl.org/docs/man1.0.2/man5/x509v3_config.html
SAN is not a valid option along with CN


... I don't see that being said in the page you refer to?

Anyhow, "stop giving a CN, use SANs instead" is a rather recent 
development coming from the CA/Browser Forum - and IIUC still not a 
*requirement*, not even for web browsers/servers. I would be surprised 
if OpenSSL (already) were trying to enforce that policy.


Hmmm, what's our company's "IMAPS server" throwing at my TB again ... ?


$ openssl s_client -connect outlook.office365.com:993 -showcerts | openssl x509 
-noout -text

[...]

Subject: C = US, ST = Washington, L = Redmond, O = Microsoft 
Corporation, CN = outlook.com

[...]
X509v3 Subject Alternative Name: 
DNS:*.clo.footprintdns.com, DNS:*.hotmail.com, DNS:*.internal.outlook.com, [...]


... yeah, no, nothing that Thunderbird (from 69-ish to 102) should get 
indigestion over.


Upoin further testing thunderbird seems to be locking onto the primary 
domain (*.scom.ca) of the server skipp any sni setup ??


You might want to get a network trace of your Thunderbird talking to the 
server to see what cert actually is presented by the server, and 
ideally, what domain is requested by SNI (if at all). That all happens 
before the connection starts to be encrypted, so you should be able to 
read it (say, with Wireshark) without having to crack any crypto ...


Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42) - sni

2022-10-11 Thread Paul Kudla (SCOM.CA Internet Services Inc.) 



ok according to

https://www.openssl.org/docs/man1.0.2/man5/x509v3_config.html

SAN is not a valid option along with CN

CN is part of the subject ??

Upoin further testing thunderbird seems to be locking onto the primary 
domain (*.scom.ca) of the server skipp any sni setup ??


again thoughts 




Happy Tuesday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email p...@scom.ca

On 10/11/2022 9:17 AM, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:



ok it appears that all this revolves around openssl

does anyone have explicit instructions on how to generate a proper ssl

key, csr etc file

with the proper SAN & CN etc

i tried

# openssl req -new -nodes -newkey rsa:2048 -config ./openssl.cnf 
-reqexts req_ext -keyout mail.paulkudla.net.key -out mail.paulkudla.net.csr

Error Loading request extension section req_ext

34371092480:error:22075075:X509 V3 
routines:v2i_GENERAL_NAME_ex:unsupported 
option:/usr/src/crypto/openssl/crypto/x509v3/v3_alt.c:534:name=SAN.1


34371092480:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in 
extension:/usr/src/crypto/openssl/crypto/x509v3/v3_conf.c:47:name=subjectAltName, value=@alt_names


and got the errors above

there not seem to be much on the web about how to generate these certs??



Happy Tuesday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email p...@scom.ca

On 10/11/2022 7:47 AM, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:



Good morning to all

i guess things have changed yet again

to keep this simple :

i buy a certificate (example) : mail.paulkudla.net

i generated the key / csr as per normal using

data = '/usr/local/bin/openssl req -new -key /tmp/temp.key -out 
/tmp/temp.csr -subj "/C=%s/ST=%s/L=%s/O=%s/CN=%s"' 
%(country,state,location,organization,self.domain)


please note the above is done in django

(yes i am running thunderbird v102)

i go buy the certificate

i database the CRT & CA

CSR is :

-BEGIN CERTIFICATE REQUEST-
MIICpzCCAY8CAQAwYjELMAkGA1UEBhMCQ0ExEDAOBgNVBAgMB09udGFyaW8xDzAN
BgNVBAcMBldoaXRieTETMBEGA1UECgwKUGF1bCBLdWRsYTEbMBkGA1UEAwwSbWFp
bC5wYXVsa3VkbGEubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
mSWAdwbxwjkjALQa4UdgOBHcFJDA5XkGI/8SswotYMnzjRAAE4S88vUTO3ltMasY
rprEvWEiEzUrRon3hh1ZZguV775fNCbyKUGKwGLKPDpmKxYCsE4gi2z7LKY13wSv
lLE8++Hqvt3cmZZ+wxWP/hy6LcS/6PvUPgN7S+cEC5TNLQ6VRZdpSGolRCrN9hsN
15GWYEQ/zcLW2PeCWav9DOr6NHBRE+fruDy3jFT0TkHWf3H+GKB0/RZ0agMJcEGc
ZLdJ1LkvNAn6gslppm3otZyu7XTvY9qZXcYOlMN0KL3a3488OwXTwWJHEN58eCMc
juax1f7ad8Z/+Pi+OFwfWQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAFgL24yi
WPat73tg1fANvutWXa2WEXeegqOawqvsV74lcyqMes8yhxiz/niOAt3oOLmViRF4
VlorgUwL0eAxtNeY4lgURW6XM5oz8TBINnPPohSAuDL9azLV1U1+M/vAvLs+LRd9
7wfVCN5bov7y735u2w38GAjmXJCBdoc+glUa+eGd5WH2+r/QQW/lRqVTDq+arqNk
9DTZc73gDCDmV45vTtbrlLnOxtmpqaQKsoFCCJW8OWaaDXfc8I+TdClVsThsbrWu
iz1/QClBPbKvfufNb+asTQSCDeJFc2EynDSE1yeYzliMLo+77ZoMqJPvI9IJCuj5
yq88NESoIYaO6Do=
-END CERTIFICATE REQUEST-

CRT is :

-BEGIN CERTIFICATE-
MIIGRTCCBS2gAwIBAgIRAKTmHoDG9LF3heBvAT8gZkYwDQYJKoZIhvcNAQELBQAw
gY8xCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0yMjA2MTYwMDAwMDBaFw0yMzA2MTYyMzU5NTlaMB0xGzAZBgNVBAMTEm1h
aWwucGF1bGt1ZGxhLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJklgHcG8cI5IwC0GuFHYDgR3BSQwOV5BiP/ErMKLWDJ840QABOEvPL1Ezt5bTGr
GK6axL1hIhM1K0aJ94YdWWYLle++XzQm8ilBisBiyjw6ZisWArBOIIts+yymNd8E
r5SxPPvh6r7d3JmWfsMVj/4cui3Ev+j71D4De0vnBAuUzS0OlUWXaUhqJUQqzfYb
DdeRlmBEP83C1tj3glmr/Qzq+jRwURPn67g8t4xU9E5B1n9x/higdP0WdGoDCXBB
nGS3SdS5LzQJ+oLJaaZt6LWcru1072PamV3GDpTDdCi92t+PPDsF08FiRxDefHgj
HI7msdX+2nfGf/j4vjhcH1kCAwEAAaOCAwswggMHMB8GA1UdIwQYMBaAFI2MXsRU
rYrhd+mb+ZsF4bgBjWHhMB0GA1UdDgQWBBROA5NFqfrlHGbkp9v1JBxZe0fZsDAO
BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcD
AQYIKwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUF
BwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUF
BwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wNQYDVR0RBC4wLIISbWFpbC5w
YXVsa3VkbGEubmV0ghZ3d3cubWFpbC5wYXVsa3VkbGEubmV0MIIBfQYKKwYBBAHW
eQIEAgSCAW0EggFpAWcAdgCt9776fP8QyIudPZwePhhqtGcpXc+xDCTKhYY069yC
igAAAYFsxJHxAAAEAwBHMEUCIQDxa9L+JaMJJImKuYPmfCAwJOiGXwECgtruOegv
vPqGpwIgWW8B0SWqVNPEFBveoBlIZF3jjj4nQIzYi2LnLizoVDMAdQB6MoxU2Lct
tiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYFsxJHJAAAEAwBGMEQCIDIgNptW
Qum0KFyemHNTTfonlq4FvWTgzR1AGUnOgotPAiAAiwyN9MjZNiP76P3fel6BqEqj
jwnSVleJR1DgLIoyPQB2AOg+0No+9QY1MudXKLyJa8kD08vREWvs62nhd31tBr1u
AAABgWzEkYoAAAQDAEcwRQIgOYjevKp5RI+c0JhIi6JflaxiNokR

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42) - sni

2022-10-11 Thread Paul Kudla (SCOM.CA Internet Services Inc.) 



ok it appears that all this revolves around openssl

does anyone have explicit instructions on how to generate a proper ssl

key, csr etc file

with the proper SAN & CN etc

i tried

# openssl req -new -nodes -newkey rsa:2048 -config ./openssl.cnf 
-reqexts req_ext -keyout mail.paulkudla.net.key -out mail.paulkudla.net.csr

Error Loading request extension section req_ext

34371092480:error:22075075:X509 V3 
routines:v2i_GENERAL_NAME_ex:unsupported 
option:/usr/src/crypto/openssl/crypto/x509v3/v3_alt.c:534:name=SAN.1


34371092480:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in 
extension:/usr/src/crypto/openssl/crypto/x509v3/v3_conf.c:47:name=subjectAltName, 
value=@alt_names


and got the errors above

there not seem to be much on the web about how to generate these certs??



Happy Tuesday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email p...@scom.ca

On 10/11/2022 7:47 AM, Paul Kudla (SCOM.CA Internet Services Inc.) wrote:



Good morning to all

i guess things have changed yet again

to keep this simple :

i buy a certificate (example) : mail.paulkudla.net

i generated the key / csr as per normal using

data = '/usr/local/bin/openssl req -new -key /tmp/temp.key -out 
/tmp/temp.csr -subj "/C=%s/ST=%s/L=%s/O=%s/CN=%s"' 
%(country,state,location,organization,self.domain)


please note the above is done in django

(yes i am running thunderbird v102)

i go buy the certificate

i database the CRT & CA

CSR is :

-BEGIN CERTIFICATE REQUEST-
MIICpzCCAY8CAQAwYjELMAkGA1UEBhMCQ0ExEDAOBgNVBAgMB09udGFyaW8xDzAN
BgNVBAcMBldoaXRieTETMBEGA1UECgwKUGF1bCBLdWRsYTEbMBkGA1UEAwwSbWFp
bC5wYXVsa3VkbGEubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
mSWAdwbxwjkjALQa4UdgOBHcFJDA5XkGI/8SswotYMnzjRAAE4S88vUTO3ltMasY
rprEvWEiEzUrRon3hh1ZZguV775fNCbyKUGKwGLKPDpmKxYCsE4gi2z7LKY13wSv
lLE8++Hqvt3cmZZ+wxWP/hy6LcS/6PvUPgN7S+cEC5TNLQ6VRZdpSGolRCrN9hsN
15GWYEQ/zcLW2PeCWav9DOr6NHBRE+fruDy3jFT0TkHWf3H+GKB0/RZ0agMJcEGc
ZLdJ1LkvNAn6gslppm3otZyu7XTvY9qZXcYOlMN0KL3a3488OwXTwWJHEN58eCMc
juax1f7ad8Z/+Pi+OFwfWQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAFgL24yi
WPat73tg1fANvutWXa2WEXeegqOawqvsV74lcyqMes8yhxiz/niOAt3oOLmViRF4
VlorgUwL0eAxtNeY4lgURW6XM5oz8TBINnPPohSAuDL9azLV1U1+M/vAvLs+LRd9
7wfVCN5bov7y735u2w38GAjmXJCBdoc+glUa+eGd5WH2+r/QQW/lRqVTDq+arqNk
9DTZc73gDCDmV45vTtbrlLnOxtmpqaQKsoFCCJW8OWaaDXfc8I+TdClVsThsbrWu
iz1/QClBPbKvfufNb+asTQSCDeJFc2EynDSE1yeYzliMLo+77ZoMqJPvI9IJCuj5
yq88NESoIYaO6Do=
-END CERTIFICATE REQUEST-

CRT is :

-BEGIN CERTIFICATE-
MIIGRTCCBS2gAwIBAgIRAKTmHoDG9LF3heBvAT8gZkYwDQYJKoZIhvcNAQELBQAw
gY8xCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0yMjA2MTYwMDAwMDBaFw0yMzA2MTYyMzU5NTlaMB0xGzAZBgNVBAMTEm1h
aWwucGF1bGt1ZGxhLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJklgHcG8cI5IwC0GuFHYDgR3BSQwOV5BiP/ErMKLWDJ840QABOEvPL1Ezt5bTGr
GK6axL1hIhM1K0aJ94YdWWYLle++XzQm8ilBisBiyjw6ZisWArBOIIts+yymNd8E
r5SxPPvh6r7d3JmWfsMVj/4cui3Ev+j71D4De0vnBAuUzS0OlUWXaUhqJUQqzfYb
DdeRlmBEP83C1tj3glmr/Qzq+jRwURPn67g8t4xU9E5B1n9x/higdP0WdGoDCXBB
nGS3SdS5LzQJ+oLJaaZt6LWcru1072PamV3GDpTDdCi92t+PPDsF08FiRxDefHgj
HI7msdX+2nfGf/j4vjhcH1kCAwEAAaOCAwswggMHMB8GA1UdIwQYMBaAFI2MXsRU
rYrhd+mb+ZsF4bgBjWHhMB0GA1UdDgQWBBROA5NFqfrlHGbkp9v1JBxZe0fZsDAO
BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcD
AQYIKwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUF
BwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUF
BwEBBHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wNQYDVR0RBC4wLIISbWFpbC5w
YXVsa3VkbGEubmV0ghZ3d3cubWFpbC5wYXVsa3VkbGEubmV0MIIBfQYKKwYBBAHW
eQIEAgSCAW0EggFpAWcAdgCt9776fP8QyIudPZwePhhqtGcpXc+xDCTKhYY069yC
igAAAYFsxJHxAAAEAwBHMEUCIQDxa9L+JaMJJImKuYPmfCAwJOiGXwECgtruOegv
vPqGpwIgWW8B0SWqVNPEFBveoBlIZF3jjj4nQIzYi2LnLizoVDMAdQB6MoxU2Lct
tiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYFsxJHJAAAEAwBGMEQCIDIgNptW
Qum0KFyemHNTTfonlq4FvWTgzR1AGUnOgotPAiAAiwyN9MjZNiP76P3fel6BqEqj
jwnSVleJR1DgLIoyPQB2AOg+0No+9QY1MudXKLyJa8kD08vREWvs62nhd31tBr1u
AAABgWzEkYoAAAQDAEcwRQIgOYjevKp5RI+c0JhIi6JflaxiNokRTSeXN6LrdIVt
Cf8CIQCG+aLreYVV8xCPV0skr0ats5zMf5PLPN2y8EIxGPPNVTANBgkqhkiG9w0B
AQsFAAOCAQEAJX544qDTgkGGLUOher7tH7yUgEhQFYkBDAirO37MXrhtuzH6pGSp
XfYVNB9e2ydprfmLDh8O8oTaXpaQfp/jwK3U0GfvG57MfdQTLOunpWnCjaMUPUcv
jPU90/mXc5oWlO5iJ6jPDkS/x47K03P6vftSr7AMwnLq4kYwuG9fHLslMHhoojen
9S2G1QjKVp5jkFecmQib+JOZV9Ub9r6iumHICfdcSO+tyBL2IDqWDQhuAVUXgyOV
11O9ZgikoeRhgsMhwiQA1z/Fs6Xqx/XCs6nUciebRiQuuHYm/PUG2H+tg0sLhJ6L
ntIEhjjkumL0oJEfDidP/8wmrsPuwfSDCQ==
-END CERTIFICATE-

CA (INTER) :

-BEGIN CERTIFICATE-
MIIGEzCCA/ugAwIBAgIQfVtRJrR2uhHbdBYLvFMNpzANBgkqhkiG9w0BAQwFADCB
iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZX

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-19 Thread Simon B 
On Sun, 18 Sept 2022 at 18:34, Jaroslaw Rafa  wrote:
>
> Dnia 18.09.2022 o godz. 10:09:34 Stuart Henderson pisze:
> >
> > The CA/Browser Forum baseline requirements say that certificates must
> > include subjectAlternativeName. This doesn't strictly apply to non-browser
> > applications but it does mean that all CA-issued certs can be relied upon
> > to have SAN.
> >
> > RFC 6125 6.4.4 says that clients must not check CN if the identifiers
> > used in subjectAlternativeName are present. So for certs following the
> > baseline requirements, checking CN is redundant. It also says that
> > clients *may* check CN but it's not required.
> >
> > There are differences in handling of name constraints between certs
> > using just CN and those using SAN. Name constraints don't really work
> > for certs using CN (by adding dc= components to the Subject, you can
> > comply with the directoryNameconstraints that apply to Subject
> > while providing a CN that is not in the expected domain). The dNSName
> > constraint applicable to SAN doesn't have this problem.
> >
> > So there's a good reason to avoid using CN when checking the name: it
> > gives defence against a CA or sub-CA with a trusted but constrained root
> > certificate that goes rogue.
> >
> > Practically this means you need to make sure that if you use self-
> > signed or internal CA certificates you include subjectAlternativeName
> > otherwise they won't work with some client software. If you use public
> > CA-signed certs you typically don't need to do this yourself because
> > the CA adds SAN if missing from the CSR (their only other option is
> > to reject issuance).
>
> I have a question regarding this:
> I always understood (maybe wrong) SAN as literally *alternate* DNS names for
> the server in addition to its basic, "canonical" DNS name, which was
> specified in the CN.
>
> For example if the server is example.com, but it also can be accessed as
> www.example.com (and both names have A records resolving to the same IP
> adddress), I put example.com into CN and www.example.com into SAN.
>
> From what you have written above, I cannot figure out if this is correct, or
> maybe should I put both names example.com and www.example.com into SAN (in
> addition to example.com being in CN)?

As per my previous reply, the CN must now be replicated/duplicated in the SAN.

So in you example a valid .csr now contains:
CN = example.com
SAN.1 = example.com
SAN.2 = www.example.com
etc.

Of course you could also have:

CN = www.example.com
SAN.1 = www.example.com
SAN.2 = example.com

Regards

Simon

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-18 Thread Simon B 
On Sun, 18 Sept 2022 at 12:53, Goetz Schultz
 wrote:
>
>
> On 18/09/2022 11:09, Stuart Henderson wrote:
> > On 2022-09-14, Goetz Schultz  wrote:
> >> I had the same issue on TB102. Self-Signed certificates rejected despite
> >> having the CA installed correctly as authority. Turns out out that that
> >> TB now wants extension "Subject Alt Names". Added that and all works
> >> now. Seems another Google pressed issue being introduced (my Chromium
> >> had same issues and rejected certs before I added SAN).
> >
> > It's not just a "Google pressed issue".
>
> Seems I was a hasty in blaming .
>

Not necessarily...  The CA Browser Forum ad[a|o]pted this partly
because Google started showing visible warnings in the Chrome Browser
when the CN was not replicated in the SAN field.

Regards

Simon

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-18 Thread Emmanuel Fusté 

Le 18/09/2022 à 18:33, Jaroslaw Rafa a écrit :
...

For example if the server is example.com, but it also can be accessed as
www.example.com (and both names have A records resolving to the same IP
adddress), I put example.com into CN and www.example.com into SAN.

 From what you have written above, I cannot figure out if this is correct, or
maybe should I put both names example.com and www.example.com into SAN (in
addition to example.com being in CN)?

Per spec, example.com AND www.example.com should be into SAN.

Emmanuel.

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-18 Thread Jaroslaw Rafa 
Dnia 18.09.2022 o godz. 10:09:34 Stuart Henderson pisze:
> 
> The CA/Browser Forum baseline requirements say that certificates must
> include subjectAlternativeName. This doesn't strictly apply to non-browser
> applications but it does mean that all CA-issued certs can be relied upon
> to have SAN.
> 
> RFC 6125 6.4.4 says that clients must not check CN if the identifiers
> used in subjectAlternativeName are present. So for certs following the
> baseline requirements, checking CN is redundant. It also says that
> clients *may* check CN but it's not required.
> 
> There are differences in handling of name constraints between certs
> using just CN and those using SAN. Name constraints don't really work
> for certs using CN (by adding dc= components to the Subject, you can
> comply with the directoryNameconstraints that apply to Subject
> while providing a CN that is not in the expected domain). The dNSName
> constraint applicable to SAN doesn't have this problem.
> 
> So there's a good reason to avoid using CN when checking the name: it
> gives defence against a CA or sub-CA with a trusted but constrained root
> certificate that goes rogue.
> 
> Practically this means you need to make sure that if you use self-
> signed or internal CA certificates you include subjectAlternativeName
> otherwise they won't work with some client software. If you use public
> CA-signed certs you typically don't need to do this yourself because
> the CA adds SAN if missing from the CSR (their only other option is
> to reject issuance).

I have a question regarding this:
I always understood (maybe wrong) SAN as literally *alternate* DNS names for
the server in addition to its basic, "canonical" DNS name, which was
specified in the CN.

For example if the server is example.com, but it also can be accessed as
www.example.com (and both names have A records resolving to the same IP
adddress), I put example.com into CN and www.example.com into SAN.

>From what you have written above, I cannot figure out if this is correct, or
maybe should I put both names example.com and www.example.com into SAN (in
addition to example.com being in CN)?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-18 Thread Goetz Schultz 



On 18/09/2022 11:09, Stuart Henderson wrote:

On 2022-09-14, Goetz Schultz  wrote:

I had the same issue on TB102. Self-Signed certificates rejected despite
having the CA installed correctly as authority. Turns out out that that
TB now wants extension "Subject Alt Names". Added that and all works
now. Seems another Google pressed issue being introduced (my Chromium
had same issues and rejected certs before I added SAN).


It's not just a "Google pressed issue".


Seems I was a hasty in blaming .

[..]


Practically this means you need to make sure that if you use self-
signed or internal CA certificates you include subjectAlternativeName
otherwise they won't work with some client software. If you use public
CA-signed certs you typically don't need to do this yourself because
the CA adds SAN if missing from the CSR (their only other option is
to reject issuance).



Thanks for the elaboration. I have it now under control to sign certs 
that have a SAN in the CSR.



Thanks and regards

  Goetz R Schultz

>8
Quis custodiet ipsos custodes?
  /"\
  \ /  ASCII Ribbon Campaign
   X   against HTML e-mail
  / \
8<

>8--

 /"\
 \ /  ASCII Ribbon Campaign
  X   against HTML e-mail
 / \ 


  This message is transmitted on 100% recycled electrons.

>8--
Unsigned message - no responsibillity that content is not altered

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-18 Thread Stuart Henderson 
On 2022-09-14, Goetz Schultz  wrote:
> I had the same issue on TB102. Self-Signed certificates rejected despite 
> having the CA installed correctly as authority. Turns out out that that 
> TB now wants extension "Subject Alt Names". Added that and all works 
> now. Seems another Google pressed issue being introduced (my Chromium 
> had same issues and rejected certs before I added SAN).

It's not just a "Google pressed issue".

The CA/Browser Forum baseline requirements say that certificates must
include subjectAlternativeName. This doesn't strictly apply to non-browser
applications but it does mean that all CA-issued certs can be relied upon
to have SAN.

RFC 6125 6.4.4 says that clients must not check CN if the identifiers
used in subjectAlternativeName are present. So for certs following the
baseline requirements, checking CN is redundant. It also says that
clients *may* check CN but it's not required.

There are differences in handling of name constraints between certs
using just CN and those using SAN. Name constraints don't really work
for certs using CN (by adding dc= components to the Subject, you can
comply with the directoryNameconstraints that apply to Subject
while providing a CN that is not in the expected domain). The dNSName
constraint applicable to SAN doesn't have this problem.

So there's a good reason to avoid using CN when checking the name: it
gives defence against a CA or sub-CA with a trusted but constrained root
certificate that goes rogue.

Practically this means you need to make sure that if you use self-
signed or internal CA certificates you include subjectAlternativeName
otherwise they won't work with some client software. If you use public
CA-signed certs you typically don't need to do this yourself because
the CA adds SAN if missing from the CSR (their only other option is
to reject issuance).

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42) [SOLVED]

2022-09-15 Thread Meikel 

Hello,

I switched from self-created SSL certificates to SSL certificates from 
Let's Encrypt. For that I configured


  ssl_cert =

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-14 Thread PGNet Dev 
cert had an invalid/incorrect hostname 



fyi,


https://kb.mozillazine.org/Files_and_folders_in_the_profile_-_Thunderbird
...
cert_override.txt
This is an optional file used to store a security 
exception. It appears to store the host name , thus preventing you from 
creating a security exception for a rotating SMTP server.
...

for ref,

Firefox: How to audit & reset the list of trusted servers/CAs
 https://access.redhat.com/solutions/1549043

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-14 Thread Goetz Schultz 

Hi,

I had the same issue on TB102. Self-Signed certificates rejected despite 
having the CA installed correctly as authority. Turns out out that that 
TB now wants extension "Subject Alt Names". Added that and all works 
now. Seems another Google pressed issue being introduced (my Chromium 
had same issues and rejected certs before I added SAN).


Thanks and regards

  Goetz R Schultz

>8
Quis custodiet ipsos custodes?
  /"\
  \ /  ASCII Ribbon Campaign
   X   against HTML e-mail
  / \
8<

On 14/09/2022 13:39, Mark Stevens wrote:

I just ran into something similar with the latest version of TB.
I updated our SSL cert for Dovecot but TB could not access my email over 
port 993.
I clicked on file then get new messages for all accounts. TB popped up a 
warning that the cert had an invalid/incorrect hostname and if I should 
allow the exception. I allowed the exception which worked and TB is fine 
now.
I only did this because my ssl cert is a wildcard for the domain but 
does not explicitly list the hostname.


Mark

On 9/14/2022 8:23 AM, Meikel wrote:

Hello.

Am 14.09.2022 um 13:59 schrieb Christian Mack:

Sound to me, as if Thunderbird does not know the CA used to (self) sign
that server certificate.


Following the documentation at

https://community.letsencrypt.org/t/simple-guide-using-lets-encrypt-ssl-certs-with-dovecot/2921 



I configured

ssl_cert = to my Let's Encrypt SSL certificates and did a restart of Dovecont and 
at least for one installation of Thunderbird it seems to work again 
now. For the other installations I need to check later at home, but 
the problem seems to be resolved.


Regards,

Meikel




>8--

 /"\
 \ /  ASCII Ribbon Campaign
  X   against HTML e-mail
 / \ 


  This message is transmitted on 100% recycled electrons.

>8--
Unsigned message - no responsibillity that content is not altered

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-14 Thread Mark Stevens 

I just ran into something similar with the latest version of TB.
I updated our SSL cert for Dovecot but TB could not access my email over 
port 993.
I clicked on file then get new messages for all accounts. TB popped up a 
warning that the cert had an invalid/incorrect hostname and if I should 
allow the exception. I allowed the exception which worked and TB is fine 
now.
I only did this because my ssl cert is a wildcard for the domain but 
does not explicitly list the hostname.


Mark

On 9/14/2022 8:23 AM, Meikel wrote:

Hello.

Am 14.09.2022 um 13:59 schrieb Christian Mack:

Sound to me, as if Thunderbird does not know the CA used to (self) sign
that server certificate.


Following the documentation at

https://community.letsencrypt.org/t/simple-guide-using-lets-encrypt-ssl-certs-with-dovecot/2921 



I configured

ssl_cert = to my Let's Encrypt SSL certificates and did a restart of Dovecont and 
at least for one installation of Thunderbird it seems to work again 
now. For the other installations I need to check later at home, but 
the problem seems to be resolved.


Regards,

Meikel

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-14 Thread Meikel 

Hello.

Am 14.09.2022 um 13:59 schrieb Christian Mack:

Sound to me, as if Thunderbird does not know the CA used to (self) sign
that server certificate.


Following the documentation at

https://community.letsencrypt.org/t/simple-guide-using-lets-encrypt-ssl-certs-with-dovecot/2921

I configured

ssl_cert = to my Let's Encrypt SSL certificates and did a restart of Dovecont and 
at least for one installation of Thunderbird it seems to work again now. 
For the other installations I need to check later at home, but the 
problem seems to be resolved.


Regards,

Meikel

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-14 Thread Christian Mack 
Hello

Sound to me, as if Thunderbird does not know the CA used to (self) sign
that server certificate.
As it does not know and trust that server certifikate for sending email,
it disconnects with that generic error.
Thunderbird has its own trusted CA store, therefore not using the one
from the OS (as Claw-Mail does).


Kind regards,
Christian Mack

Am 14.09.22 um 13:14 schrieb Meikel:
> Hi folks,
> 
> on a Rocky Linux 8.6 based home server I run Dovecot with an account
> that I use as an archive. Archive means, that from different Thunderbird
> instances I connect to that Dovecot via IMAPS to move emails there, that
> I want to keep. Since some days from all Thunderbird instances I can no
> longer connect to that Dovecot account. In /var/log/maillog of the
> server I see
> 
> Sep 14 06:39:54 server3 dovecot[2033173]: imap-login: Disconnected:
> Connection closed: SSL_accept() failed: error:14094412:SSL
> routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number
> 42 (no auth attempts in 0 secs): user=<>, rip=192.168.177.105,
> lip=192.168.177.13, TLS handshaking: SSL_accept() failed:
> error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:
> SSL alert number 42, session=
> 
> I found that Openssl alert number 42 might be a problem with the SSL
> certificate (which certificate?) but also might be an expired SSL
> certificate (which certificate?). As on the Dovecot installation I work
> with a self signed certificat. I created a new self signed certificate
> yesterday with an expiry not before year 2032. That did not help, I see
> the same messages when I try to connect from Thunderbird.
> 
> Just to see how Thunderbird is involved in the problem I installed
> Claws-Mail. From Claws-Mail I do NOT have those problems, I can access
> to Dovecot via IMAPS as expected.
> 
> I do not understand why all my Thunderbird installations can no longer
> access Dovecot via IMAPS. This worked fine for about 18 months. I can't
> prove but I think on beginning of month it worked fine. Something
> happened meanwhile.
> 
> If there is a problem with an SSL certificate (bad certificate: SSL
> alert number 42), which certificate makes the problem? The certificate
> used by Dovecot or some certificate used in Thunderbird?
> 
> About installation:
> 
> cat /etc/redhat-release
> Rocky Linux release 8.6 (Green Obsidian)
> 
> dovecot --version
> 2.3.16 (7e2e900c1a)
> 
> sudo dovecot -n
> # 2.3.16 (7e2e900c1a): /etc/dovecot/dovecot.conf
> # OS: Linux 4.18.0-372.19.1.el8_6.x86_64 x86_64 Rocky Linux
>  release 8.6 (Green Obsidian)
> # Hostname: ...
> auth_debug = yes
> auth_mechanisms = plain login
> auth_verbose = yes
> first_valid_uid = 1000
> mail_debug = yes
> mail_gid = vmail
> mail_location = maildir:~/Maildir
> mail_privileged_group = vmail
> mail_uid = vmail
> mbox_write_locks = fcntl
> namespace {
>   inbox = yes
>   location =
>   mailbox Archives {
>     special_use = \Archive
>   }
>   prefix = INBOX/
>   separator = /
>   type = private
> }
> passdb {
>   args = scheme=CRYPT username_format=%u /etc/dovecot/users
>   driver = passwd-file
> }
> protocols = imap
> service imap-login {
>   inet_listener imap {
>     port = 0
>   }
> }
> ssl = required
> ssl_cert =  ssl_cipher_list = PROFILE=SYSTEM
> ssl_key = # hidden, use -P to show it
> userdb {
>   args = username_format=%u /etc/dovecot/users
>   driver = passwd-file
> }
> verbose_proctitle = yes
> 
> I used the following command to recreate the SSL certificate for Dovecot:
> 
> sudo openssl req -x509 -nodes -days 3650 -newkey rsa:4096
>  -keyout /etc/dovecot/..key -out /etc/dovecot/..crt
> 
> And with the command
> 
> openssl s_client -crlf -connect .:993
> 
> I can successfully connect to Dovecot and "simulate" a minimal
> IMAP-Session:
> 
> * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE
>  IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot ready
> a login meikel.archive@. topsecret
> a OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE
>  IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS
>  THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE
>  UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED
>  I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES
>  WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE
>  SNIPPET=FUZZY PREVIEW=FUZZY LITERAL+ NOTIFY
>  SPECIAL-USE] Logged in
> a logout
> * BYE Logging out
> a OK Logout completed (0.001 + 0.000 secs).
> closed
> 
> I have the problem with different Thunderbird installations on various
> operating systems (Windows 10, Fedora Linux 36 XFCE).
> 
> Regards,
> 
> Meikel
> 


-- 
Christian Mack
Universität Konstanz
Kommunikations-, Informations-, Medienzentrum (KIM)

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

2022-09-14 Thread spi 


Am 14.09.22 um 13:14 schrieb Meikel:

Hi folks,

on a Rocky Linux 8.6 based home server I run Dovecot with an account
that I use as an archive. Archive means, that from different
Thunderbird instances I connect to that Dovecot via IMAPS to move
emails there, that I want to keep. Since some days from all
Thunderbird instances I can no longer connect to that Dovecot account.
In /var/log/maillog of the server I see

Sep 14 06:39:54 server3 dovecot[2033173]: imap-login: Disconnected:
Connection closed: SSL_accept() failed: error:14094412:SSL
routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number
42 (no auth attempts in 0 secs): user=<>, rip=192.168.177.105,
lip=192.168.177.13, TLS handshaking: SSL_accept() failed:
error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad
certificate: SSL alert number 42, session=

I found that Openssl alert number 42 might be a problem with the SSL
certificate (which certificate?) but also might be an expired SSL
certificate (which certificate?). As on the Dovecot installation I
work with a self signed certificat. I created a new self signed
certificate yesterday with an expiry not before year 2032. That did
not help, I see the same messages when I try to connect from Thunderbird.

Just to see how Thunderbird is involved in the problem I installed
Claws-Mail. From Claws-Mail I do NOT have those problems, I can access
to Dovecot via IMAPS as expected.

I do not understand why all my Thunderbird installations can no longer
access Dovecot via IMAPS. This worked fine for about 18 months. I
can't prove but I think on beginning of month it worked fine.
Something happened meanwhile.

If there is a problem with an SSL certificate (bad certificate: SSL
alert number 42), which certificate makes the problem? The certificate
used by Dovecot or some certificate used in Thunderbird?

...
I have the problem with different Thunderbird installations on various
operating systems (Windows 10, Fedora Linux 36 XFCE).

Regards,

Meikel


Is this a self signed certificate? In the past I had issues with Firefox
and self signed certificates on my servers. They worked in Chromium but
not Firefox. Mozilla is a bit more niggling about certificates - I'd
expect the same engine in Thunderbird. I had an issue with the X509v3
extension in my certificate and one day Firefox didn't accept these
certificates any longer.

If this is the case you can either create new certificates or - if this
is a workaround for you - accept the certificate in Thunderbird (you
might have to import it manually into Thunderbird first and adopt its
trust level). I don't like the latter as it needs to be done on every
client and might break trust in future.

--
Cheers
spi