Closed Bug 1777717 Opened 3 years ago Closed 3 years ago

Thunderbird 102 says my mail server's cert "belongs to a different site" because it lacks a subjectAltName (expected per bug 1691122)

Categories

(Thunderbird :: Security, defect)

Product:
Thunderbird
Component:
Security
Version:
Thunderbird 102
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: smichaud, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [closeme 2022-09-05 INVALID][needs documentation])

Attachments

(4 files)

My CA Server's certificate
1.64 KB, application/x-x509-ca-cert
Details
Cert for my frankenserver mail server
1.45 KB, application/x-x509-ca-cert
Details
Cert for my igor mail server
1.44 KB, application/x-x509-ca-cert
Details
PoorMansCA document (part of it)
1.73 KB, text/plain
Details

I have several local IMAP/SMTP servers that I've been using for a long time. Prior versions of Thunderbird (up through 91.11.0) have no problems with them. But Thunderbird 102 can't send mail to them or retrieve mail from them.

All my servers use Dovecot for IMAP and Postfix for SMTP. One of them (the one I've used the longest) is part of an old OS X Server setup. The others I've set up myself in emulation of the first one. They're all set up to refuse insecure connections. I'm also running my own DNS server (on the OS X Server). My local network is private -- I call it "bagend.private".

The certificates I'm using are ones I created "by hand", using openssl commands. So they're quite minimal. But they are formatted correctly. In later comments I'll post public certs for my CA Server and two of my email servers (the original OS X Server one, called igor.bagend.private, and a testing server called frankenserver.bagend.private).

I have no problems setting up accounts for these servers -- Thunderbird 102's autodetect works correctly on them. But when I try to get mail from them, nothing happens at all -- I'm not even prompted for a password. And when I try to send mail a dialog pops up with the following errors. But the information isn't invalid, and the certificate does not belong to a different site.

Location: frankenserver.bagend.private:587
This site attempts to identify itself with invalid information.
Wrong Site
The certificate belongs to a different site, which could mean that someone is trying to impersonate this site.

Before I set up any accounts, I imported my CA Server's certificate into Thunderbird 102's list of authorities, as I have done with previous versions of Thunderbird.

I'm running Thunderbird 102 on macOS 10.15.7 build 19H1922. But I have no reason to believe that this bug is macOS specific.

openssl x509 -in BagendCA-renewal1.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            3d:8f:d6:4b:00:d1:a2:f7:40:65:e0:99:c4:44:fa:cc:53:26:b5:82
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Illinois, L=Sycamore, O=Bag End, CN=Bag End Internal CA/emailAddress=smichaud@pobox.com
        Validity
            Not Before: Feb 20 21:17:03 2021 GMT
            Not After : Feb 18 21:17:03 2031 GMT
        Subject: C=US, ST=Illinois, L=Sycamore, O=Bag End, CN=Bag End Internal CA/emailAddress=smichaud@pobox.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c3:3b:b1:4a:e3:ba:d5:aa:05:fa:84:67:36:e0:
                    ca:11:f5:29:82:8f:94:c4:a9:cc:06:d1:4e:1c:f7:
                    7a:76:07:0e:47:9b:3c:ac:55:30:3c:5d:c2:d5:43:
                    2d:7b:20:46:40:36:98:23:93:21:58:5f:46:ee:f9:
                    03:97:1a:01:4f:4e:dc:13:3d:4f:40:fe:25:aa:dc:
                    b6:16:2c:85:62:52:dd:73:02:a8:64:ff:e5:0e:9f:
                    6a:2b:79:3c:d5:cc:9e:72:74:9b:f5:6c:c1:6b:ea:
                    ef:20:14:33:5e:23:82:14:43:22:cf:43:35:35:a3:
                    a9:d7:9b:a8:96:1f:d5:ff:f4:51:6b:2e:a7:ae:96:
                    bc:d0:5b:a3:53:29:71:92:97:f2:7e:4c:1f:ed:56:
                    4b:a6:4d:de:03:c8:ff:33:b4:3a:cc:ea:0a:e3:a3:
                    20:f0:e5:8f:a5:49:9c:fc:da:9d:95:99:2a:5b:07:
                    91:55:21:f6:85:bd:9c:9a:7a:fc:3e:82:4a:a0:a5:
                    2c:9d:26:10:b9:25:17:37:33:2c:c9:5b:f3:ed:fb:
                    1d:b6:4b:10:05:ef:a7:06:b1:bb:f9:5f:82:d3:4a:
                    75:eb:c7:80:f8:fd:4c:2d:af:88:9c:90:69:dc:80:
                    9b:c0:d8:c1:b3:48:bf:a4:4f:55:81:27:9b:66:e5:
                    9a:7d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier: 
                28:00:D0:72:F8:B7:36:F0:12:43:BA:B7:29:DC:45:70:2A:55:7A:48
            X509v3 Authority Key Identifier: 
                keyid:28:00:D0:72:F8:B7:36:F0:12:43:BA:B7:29:DC:45:70:2A:55:7A:48
                DirName:/C=US/ST=Illinois/L=Sycamore/O=Bag End/CN=Bag End Internal CA/emailAddress=smichaud@pobox.com
                serial:3D:8F:D6:4B:00:D1:A2:F7:40:65:E0:99:C4:44:FA:CC:53:26:B5:82

    Signature Algorithm: sha256WithRSAEncryption
         6f:44:26:d2:b6:c7:72:f0:46:43:aa:09:59:15:ee:aa:c6:84:
         6e:49:4f:20:46:6c:0f:89:e0:85:6d:33:f6:76:f7:75:0d:cf:
         61:9f:73:cc:d0:60:52:54:6e:e0:25:a5:ef:74:bd:ea:ee:d6:
         31:b1:55:87:a7:07:c3:74:d2:1c:4d:8e:ed:37:3f:b2:10:76:
         61:ce:48:6d:3f:c9:c6:c9:a3:57:98:5d:3c:f8:f8:9b:9a:d4:
         57:a1:5d:a0:8f:93:37:a6:65:80:5c:e5:4b:22:c4:b1:a6:51:
         56:80:5c:b3:01:8c:f9:5c:80:06:9f:0f:e2:cd:8f:a7:5b:80:
         bd:8a:8e:d9:67:5b:cd:4f:5c:c1:f2:9d:c8:b7:e7:bb:07:fe:
         6c:bf:f2:f8:ad:30:cb:65:53:93:6f:0f:4b:31:8d:5f:1d:83:
         8e:ef:18:26:f2:e5:a6:50:e8:9e:27:4e:19:20:1f:f3:7c:de:
         c1:f2:0b:fa:bf:54:44:3a:e9:c4:c4:60:9f:cd:4f:5f:b4:27:
         26:b8:79:c9:ed:2b:2b:cd:09:c1:57:2e:e8:c6:f9:cb:9f:9b:
         49:26:5a:72:17:8b:29:95:35:fd:d3:84:49:a0:e0:36:44:3d:
         b3:72:4c:6d:b5:c2:27:f9:d8:05:7f:0f:d4:6b:5b:cc:10:a6:
         86:1d:cc:96

openssl x509 -in frankenserver.pem -text    
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            02:e2:87:2d:5c:93:6f:f4:b2:49:8d:75:15:df:e2:24:66:1d:41:3a
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Illinois, L=Sycamore, O=Bag End, CN=Bag End Internal CA/emailAddress=smichaud@pobox.com
        Validity
            Not Before: Jun  2 17:14:05 2022 GMT
            Not After : May 30 17:14:05 2032 GMT
        Subject: C=US, ST=Illinois, L=Sycamore, O=Bag End, CN=frankenserver.bagend.private/emailAddress=smichaud@pobox.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:bb:10:8b:a0:df:59:02:45:4b:2e:00:f8:75:05:
                    8d:65:b9:6c:99:ba:38:ed:d0:14:22:af:5a:85:a6:
                    95:4b:9d:83:d6:29:de:58:28:6c:a9:65:62:d1:bb:
                    6b:27:5a:7f:1c:0c:f7:e1:1c:59:74:57:d7:28:bd:
                    7a:c2:b0:36:24:ec:33:c3:da:f9:5d:1f:82:2e:8e:
                    e0:06:1e:66:c2:c5:78:8c:cb:51:70:ad:20:e6:bc:
                    1b:18:13:09:c3:1a:7b:29:af:b1:8d:89:f6:21:9b:
                    9a:e2:d4:c5:d9:50:33:48:f1:90:a6:67:1f:a3:04:
                    d2:6b:a3:54:71:cb:fb:55:45:c4:61:9b:28:fd:01:
                    09:41:9f:41:14:e3:ed:43:df:40:9c:4d:51:af:b9:
                    e2:da:4c:9c:6d:c8:e9:bb:1c:b0:3f:28:d2:bf:2a:
                    50:2c:a9:ad:32:38:68:7b:d7:51:2c:d1:ef:7e:9a:
                    c9:c4:24:91:34:be:fc:21:0f:6f:85:a5:85:06:ed:
                    b3:a9:b8:da:c3:77:8c:6b:e8:ab:b6:8c:b8:7c:4e:
                    27:d3:cc:4b:1c:7d:14:da:02:2b:50:d5:4d:f1:f1:
                    1d:ad:18:39:34:67:0b:ad:9d:22:23:26:2b:56:85:
                    6d:32:7a:1d:8a:b5:0c:a1:8c:d0:cc:98:a7:84:5a:
                    7d:09
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage: critical
                TLS Web Server Authentication
            X509v3 Subject Key Identifier: 
                51:02:5E:B9:BA:97:3A:2E:FD:24:0A:9C:A5:BC:62:F1:0D:C2:B1:2C
            X509v3 Authority Key Identifier: 
                keyid:28:00:D0:72:F8:B7:36:F0:12:43:BA:B7:29:DC:45:70:2A:55:7A:48

    Signature Algorithm: sha256WithRSAEncryption
         55:3b:19:2f:ee:d8:3a:d8:0c:b5:fd:07:83:d7:9d:f8:3b:a1:
         c1:d3:cc:78:49:1d:3c:c4:05:67:40:a1:bc:43:f4:44:89:64:
         b6:09:12:e2:52:24:79:ae:3f:e3:67:0e:95:7d:1f:4f:c2:82:
         3f:a9:a2:10:0a:db:f7:96:e8:a5:b4:d7:87:77:ab:66:a9:50:
         45:67:2c:d7:82:71:e5:f4:c6:26:7b:35:47:53:d5:24:b9:2c:
         b5:fe:8c:d7:6f:54:3f:da:20:5a:d4:5d:26:6d:5b:83:91:6d:
         bf:03:5b:c5:1e:5a:93:0e:f4:6f:b5:e9:c6:36:83:f0:40:35:
         a8:81:b0:97:51:85:8c:af:f9:95:b7:f0:0c:93:b2:6d:72:85:
         ee:50:10:a7:78:86:8a:c9:92:89:ba:07:b7:b6:15:14:79:a0:
         3e:bc:8b:0f:40:bd:f5:d2:5c:ce:41:1c:e7:19:ac:e0:b8:5a:
         d4:14:0a:ef:05:18:79:50:54:83:35:18:90:5e:c5:12:4d:33:
         2d:f2:a9:04:d8:d4:bc:64:5c:f0:0f:45:73:d1:bf:7d:4e:f6:
         99:ef:53:31:c7:b7:97:50:e9:a7:9b:71:8c:c5:5f:24:4f:74:
         22:9a:a5:c5:ed:8f:17:c7:43:db:54:68:4c:57:1a:ba:f3:56:
         94:8b:52:8b

openssl x509 -in igor.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            02:e2:87:2d:5c:93:6f:f4:b2:49:8d:75:15:df:e2:24:66:1d:41:39
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Illinois, L=Sycamore, O=Bag End, CN=Bag End Internal CA/emailAddress=smichaud@pobox.com
        Validity
            Not Before: Jun  2 16:52:49 2022 GMT
            Not After : May 30 16:52:49 2032 GMT
        Subject: C=US, ST=Illinois, L=Sycamore, O=Bag End, CN=igor.bagend.private/emailAddress=smichaud@pobox.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9b:c8:5d:6e:e3:71:81:73:dc:16:e6:a3:11:7b:
                    96:d1:82:df:3e:d4:0c:39:b5:1e:6e:0e:2a:a5:8d:
                    5d:64:9b:bc:47:73:71:9f:17:5f:97:8e:31:93:d4:
                    60:ea:db:b7:f1:5f:11:20:8e:32:1c:1d:1d:31:5a:
                    e1:56:01:82:38:20:f9:82:c6:67:4d:fe:2f:41:4c:
                    94:21:52:9f:ab:11:b5:d0:d1:da:42:8e:13:9c:56:
                    06:0b:96:15:18:aa:ee:f4:b9:82:08:5e:21:92:00:
                    a1:e2:32:68:08:64:53:93:94:75:c7:8a:9c:f9:38:
                    1c:db:bd:a0:13:3b:b2:67:96:35:3f:c1:ff:e1:3f:
                    07:db:be:0d:80:f4:53:62:f6:52:bc:b5:a2:74:49:
                    af:1d:87:3c:7d:39:95:6a:7f:d4:00:87:ac:4f:53:
                    17:59:2b:66:b1:cf:3b:94:cc:7d:14:3b:e9:52:07:
                    12:8c:29:a3:c5:aa:42:a8:a2:72:83:91:b3:4f:bb:
                    b1:57:55:0d:02:d9:26:f4:74:ed:59:24:a5:ed:ed:
                    a1:5f:48:4b:f8:9c:67:9f:b6:1a:20:d9:e5:f6:c1:
                    85:9e:32:9d:96:1e:b2:ed:67:d8:dc:e7:e8:37:fd:
                    42:c7:2d:5d:79:6c:f2:11:c7:81:42:b8:02:e0:34:
                    c5:77
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage: critical
                TLS Web Server Authentication
            X509v3 Subject Key Identifier: 
                15:73:D2:54:FD:36:B1:02:93:23:38:72:00:D6:5F:E0:3B:29:8A:0C
            X509v3 Authority Key Identifier: 
                keyid:28:00:D0:72:F8:B7:36:F0:12:43:BA:B7:29:DC:45:70:2A:55:7A:48

    Signature Algorithm: sha256WithRSAEncryption
         41:a2:7e:a5:99:32:2d:6d:16:73:f8:33:9f:2f:39:ec:bf:83:
         98:70:1e:a0:de:9f:68:74:fa:26:a1:ee:ff:71:ae:50:f8:17:
         4b:cb:58:60:8a:d3:8a:73:45:46:27:02:dd:41:39:1b:0b:3f:
         27:63:ba:bd:05:e7:c3:7e:7e:67:00:7e:1a:50:65:a0:37:2a:
         5d:2d:14:ce:c8:91:ce:7a:4f:a2:9b:78:e7:5f:bf:cb:78:a0:
         a2:4a:9a:1e:83:23:b1:69:31:76:39:98:d4:99:df:46:9b:b4:
         76:d0:c7:53:04:c5:6d:a8:77:42:68:40:39:c4:b2:9e:dd:c0:
         76:06:0a:42:61:07:14:2a:a0:d7:d7:6e:0b:4b:91:46:55:26:
         be:4c:4a:54:11:d0:f6:94:9a:fe:7b:07:82:d8:3a:28:18:50:
         61:95:41:61:49:1b:f9:22:d3:d2:03:71:24:88:ca:ea:9c:6b:
         63:8c:f7:12:9c:23:e5:66:01:e7:6b:3f:a5:1a:af:40:09:54:
         a3:ab:49:20:3d:c2:63:fd:8b:2d:6b:4d:61:57:d3:67:db:7a:
         13:bd:fe:21:b7:59:5a:e5:d8:3b:94:71:4a:1e:05:5f:2a:e1:
         5a:14:45:ee:28:e0:ab:9f:39:95:8e:63:b3:ce:0c:3e:67:e1:
         73:b5:5b:5c

Here are the Thunderbird account settings for my email servers. They're identical to settings from previous versions of Thunderbird, which work fine on the same servers.

Server Type: Imap Mail Server
Server Name: frankenserver.bagend.private     Port: 143
User Name: smichaud
Connection Security: STARTTLS
Authentication Method: Normal password

SMTP Server
Server Name: frankenserver.bagend.private
Port: 587
Connection Security: STARTTLS
Authentication Mathod: No authentication

Here's part of a document that I maintain for myself, which shows how I use openssl to generate my certs "by hand".

I've found the regression range for this bug. The last good comm-central nightly is http://ftp.mozilla.org/pub/thunderbird/nightly/2022/04/2022-04-29-04-10-04-comm-central/thunderbird-101.0a1.en-US.mac.dmg, and the first bad one is http://ftp.mozilla.org/pub/thunderbird/nightly/2022/04/2022-04-30-10-33-09-comm-central/thunderbird-101.0a1.en-US.mac.dmg.

That translates into https://hg.mozilla.org/comm-central/pushloghtml?fromchange=a5f6ce11868f4a991b290bd411de007901f3bd93&tochange=6236676f41d4ecb5a35da4bbef6d3018c7b2bee9.

But I can't make any sense of this. I've no idea which of these changes could have triggered this bug.

At some point I'll try hg bisect to see what I get.

Edit: I suppose this bug might have been triggered by a change to mozilla-central code. I'll explore that possibility, too.

Keywords: regression
Component: General → Security

As best I can tell, here's the mozilla-central regression range that corresponds to the comm-central regression range from comment #6:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a3002a9b4204308cd68ca46d7aeb140f0ba497f7&tochange=6e268f45bed2487cce05cfae5cabb7c1c8f415a6

Once again, nothing stands out. But it gives me more to play with.

Anyone know of a way to do the equivalent of about:buildconfig in Thunderbird builds? I'm particularly interested in knowing exactly which mozilla-central changeset a given Thunderbird build was built with. I'm beginning to think the answer to this might not be what you'd expect.

Menu Help > More Troubleshooting Information.

Or you could set in Settings > General the start page to about:buildconfig.

(In reply to Richard Marti (:Paenglab) from comment #9)

Menu Help > More Troubleshooting Information.

Or you could set in Settings > General the start page to about:buildconfig.

Thanks! That's very helpful.

This information should be a little easier to find, though. I didn't have any luck searching on 'Thunderbird "about:buildconfig"' or 'Thunderbird "about buildconfig"'.

Making either of the endpoint changesets from comment #7 the current "parent" in comm-central code (using hg update -r) makes no difference here. So I proceeded to use hg bisect on mozilla-central code. It found the culprit:

The first bad revision is:
changeset:   615623:90a96fdbd3c4
user:        John Schanck <jschanck@mozilla.com>
date:        Thu Apr 28 19:48:06 2022 +0000
summary:     Bug 1691122 - Remove subject common name fallback support in CertVerifier. r=keeler,necko-reviewers,kershaw

I always thought that a server cert's CN (common name) was exactly the right place to put the server's FQDN. I'll need to look further into the matter.

But in the meantime let's mark this bug has having been regressed by bug 1691122.

Regressed by: 1691122

Google has the following to say on the topic of "commonName matching in certificates".

RFC 2818 says:

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

I'm going to wait and see what the experts decide on this matter.

Since I created my server certs "by hand" (using openssl commands), I should be able to learn how to add "subjectAltName" field(s) to them.

The fact that (as far as I know) no-one else has reported similar problems seems to indicate that the "existing practice" of using the commonName field is no longer common. But I think we should wait a while to see how things play out.

Summary: Thunderbird 102 says incorrectly that my mail server's cert "belongs to a different site" → Thunderbird 102 says my mail server's cert "belongs to a different site" because is lacks a subjectAltName
Summary: Thunderbird 102 says my mail server's cert "belongs to a different site" because is lacks a subjectAltName → Thunderbird 102 says my mail server's cert "belongs to a different site" because it lacks a subjectAltName

I've now learned how to add a subjectAltName to each of my server certs, using openssl commands. openssl doesn't make this easy -- the assumption that a server's FQDN should be in its cert's commonName field, and only there, is deeply baked in. But I managed to find a way that isn't too clumsy. Here it is as a diff on my PoorMansCA-part.txt document from comment #5:

--- PoorMansCA-part-old.txt	2022-06-09 14:47:42.000000000 -0500
+++ PoorMansCA-part.txt	2022-07-03 12:35:38.000000000 -0500
@@ -31,7 +31,7 @@
 
 7) Create and sign a cert for the server:
 
-openssl x509 -req -days 3650 -in server.csr -extfile server.cnf -extensions v3_usr -CA PoorMansCA.pem -CAkey PoorMansCAPrivKey.pem -CAcreateserial -out server.pem
+ALT_NAME=[server fqdn] openssl x509 -req -days 3650 -in server.csr -extfile server.cnf -extensions v3_usr -CA PoorMansCA.pem -CAkey PoorMansCAPrivKey.pem -CAcreateserial -out server.pem
 
 The contents of server.cnf are:
 
@@ -42,6 +42,7 @@
 extendedKeyUsage=critical,serverAuth
 subjectKeyIdentifier=hash
 authorityKeyIdentifier=keyid,issuer
+subjectAltName=DNS:$ENV::ALT_NAME
 
 8) Create a pkcs12 file for the server:

I'm now past caring about this bug, at least personally. But I think it should stay open for a while, to catch any fallout from moving to Thunderbird 102 as the default release.

Blocks: tb102found

Reading bug 1691122 it does sound like this is expected behavior.

Flags: needinfo?(jschanck)

I don't really expect bug 1691122 to get backed out. But I'd like this bug to stay open a while, to make it more visible to people like me, who were (at first) completely flummoxed by the change. It'd also be nice to get it written up on Thunderbird Support.

I frankly disagree with the decision in RFC 2818 to deprecate the use of the Common Name to store a server's fully qualified domain name. In a simple environment, where the server has only one FQDN, what else is the Common Name for? I do understand that most commercial and institutional servers don't live in such a simple environment, and have multiple FQDNs -- that's what the Subject Alternative Name (aka dNSName) is for. But why then go on to eliminate the Common Name?

However, I also understand that RFC 2818 was published long ago (more than 20 years), and since then commercial and institutional certificate authorities have conformed to its recommendation, probably almost unanimously. To change the precedent now would just confuse things.

The only holdouts seem to be the openssl utilities and (probably) the various scripts used to create self-signed certs. I doubt these will ever change at their source. But it isn't too hard for users to modify them at need ... as long as they understand how and why they need to be modified.

The only holdouts seem to be the openssl utilities and (probably) the various scripts used to create self-signed certs.

I just discovered that the mkcert utility adds a Subject Alternative Name (aka dNSName) to the self-signed certs it generates. There are others I haven't yet tried -- notably the make-ssl-cert utility that comes with Debian. But it may be that the only important holdouts are the openssl utilities.

Summary: Thunderbird 102 says my mail server's cert "belongs to a different site" because it lacks a subjectAltName → Thunderbird 102 says my mail server's cert "belongs to a different site" because it lacks a subjectAltName (expected per bug 1691122)
Whiteboard: [closeme 2022-09-05 INVALID][needs documentation]

I just installed Ubuntu Linux (a Debian clone) on a VM and ran sudo make-ssl-cert generate-default-snakeoil in it to generate a "snakeoil" cert. It includes a Subject Alternative Name.

So I think we can assume that current (well-maintained) scripts to generate self-signed certs will create certs that contain a correctly formatted subjectAltName field.

The final hurdle is documenting ways to use openssl commands to generate self-signed certs that contain a subjectAltName field. (Most people won't have the patience to emulate my PoorMansCA doc from comment #5.) There are many ways to do this, all quite clumsy. Whoever writes up the documentation should quote several examples.

Here's one based on my PoorMansCA doc:

1) Create a certificate request:

openssl req -newkey rsa:2048 -keyout serverPrivKey.pem -out server.csr -nodes

2) Convert the certificate request into a self-signed cert:

ALT_NAME=[server fqdn] openssl x509 -req -days 3650 -in server.csr -extfile website.cnf -extensions v3_usr -signkey serverPrivKey.pem -out server.pem

The contents of website.cnf are:

[ v3_usr ]
basicConstraints=CA:FALSE
#nsCertType=client,email
keyUsage=critical,digitalSignature,keyEncipherment,dataEncipherment,keyCertSign
extendedKeyUsage=critical,serverAuth
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
subjectAltName=DNS:$ENV::ALT_NAME

See also:

https://stackoverflow.com/questions/21488845/how-can-i-generate-a-self-signed-certificate-with-subjectaltname-using-openssl
https://gist.github.com/KeithYeh/bb07cadd23645a6a62509b1ec8986bbc

Flags: needinfo?(jschanck)
See Also: → 1792889

In my opinion this bug is INVALID.

Thunderbird is a client. It can be used to connect to well-configured servers.

As I understand this bug report, you have attempted to connect to a server that wasn't configured according to latest industry standards.

In my opinion it's out of scope for the Thunderbird client to describe or document how to set up servers correctly.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID

As I said above, this is what I expected to happen.

But the standard imposed by RFC 2818 (wrt Subject Alternative Names) is, to say the least, counterintuitive. Mozilla (i.e. not just Thunderbird) still needs documentation to help people out who bump into this issue. At first it seemed like I might be the only one, but we've been seeing more and more, lately.

(In reply to Kai Engert (:KaiE:) from comment #22)

In my opinion this bug is INVALID.

I disagree.

Thunderbird is a client. It can be used to connect to well-configured servers.

Be conservative in what you do, be liberal in what you accept from others. -- Jon Postel
https://en.wikipedia.org/wiki/Robustness_principle

As I understand this bug report, you have attempted to connect to a server that wasn't configured according to latest industry standards.

Omitting a SAN complies with industry standards just as much as including it. While it might be an outdated way of doing things, it's not the wrong way. It is in fact the simplest way.

In my opinion it's out of scope for the Thunderbird client to describe or document how to set up servers correctly.

While this might be true, Thunderbird should at least give a reason why it's refusing to talk to some server.
(see bug 1783615)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: