Thunderbird - exim - dovecot cert settings

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: smtp.xtronics.com

I ran this command: openssl s_client -servername smtp.xtronics.com -connect malaysia:imaps

# openssl s_client -servername smtp.xtronics.com -connect malaysia:imaps
CONNECTED(00000003)
depth=0 CN = smtp.xtronics.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = smtp.xtronics.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = smtp.xtronics.com
verify return:1
---
Certificate chain
 0 s:CN = smtp.xtronics.com
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 27 08:01:15 2023 GMT; NotAfter: Sep 25 08:01:14 2023 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEJTCCAw2gAwIBAgISBCah7iqFgjKroZqADmIB66/nMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzA2MjcwODAxMTVaFw0yMzA5MjUwODAxMTRaMBwxGjAYBgNVBAMT
EXNtdHAueHRyb25pY3MuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1hYO
1ZTtgl8zU2EBdXuNSemDdtukj9mVN8LHI4g9QEPUub7kjNvysWIgFHUtm/VBDfLD
uq1xvDpN3x/q2R20bKOCAhQwggIQMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUsyNw
YQE2GHDDCWGtqxhXQ9TuTFAwHwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsU
wsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vcjMuby5sZW5j
ci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9yZy8wHAYDVR0R
BBUwE4IRc210cC54dHJvbmljcy5jb20wEwYDVR0gBAwwCjAIBgZngQwBAgEwggEF
BgorBgEEAdZ5AgQCBIH2BIHzAPEAdgC3Pvsk35xNunXyOcW6WPRsXfxCz3qfNcSe
HQmBJe20mQAAAYj8Fe/qAAAEAwBHMEUCIQCs4VOg+Vcg8/eVT8SL2GwKxj/QSnGw
dIJ17a4L297IcwIgGFwLmGv2NpiJKgowG6IHbZ+TOGAg4ZXs/vyCzaaKVcIAdwB6
MoxU2LcttiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYj8FfHsAAAEAwBIMEYC
IQD+8cXMqL2zfjlRl/ZZPKH0rKYxt8ac5zqyMcS8KvcioAIhAPrxeaM9KCQctH57
iDZKz4raywyEtV4IR1y8NcAr+QaPMA0GCSqGSIb3DQEBCwUAA4IBAQBEWIliCfYB
Z1aulr4xMz/wwSJdZCpBhKrFeg/Knb0fQaLREBB8JW38B13a54wyyA00qwJsuloR
ETE9k9KfaLQMd2G3Dfzxz8zwdp1n1sonX5J1Z1B2H7+UXuPnVlrO6I/eQN61Oe4i
eCGr6VAX+TQmedbG1yVz+oZHgXF4DZr1A2xPoaSGjd+VudkC0yGlH8oUMU2USIOC
1Ik7zLausaJNt+SdRWhnhHPIGcRHZuEQm1s1VzYD8qW0Cl6in/30ZKz4cTobwInF
KBbACUKMe8Q2fybglGBZJ7lwpEhvsm6cobGNkElCZvTDAby8zcnIVNOl5oNFXNZ9
zEVqoFAfYxJU
-----END CERTIFICATE-----
subject=CN = smtp.xtronics.com
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1439 bytes and written 403 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 94256D0BABA2EDDCB478BDF0AA30328B70DCC849E221F6CB673EF0770DA83D8A
    Session-ID-ctx: 
    Resumption PSK: C4D1EA17EB1DCCE1B8B8B4EF0AC70098D4960209E8468EC0CC95383AC15DB38F82FEE0EA78F7FAFBB6B603FA21476F1D
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 2a 89 33 cb 28 dd 4e 91-c1 91 69 cd 7d 9e 96 47   *.3.(.N...i.}..G
    0010 - 8f 36 67 97 4e a0 d0 e7-2f 11 58 16 e5 c1 d7 4c   .6g.N.../.X....L
    0020 - 7a c7 1b 24 92 46 9d 91-bf b9 a1 cc a9 ab 5a 53   z..$.F........ZS
    0030 - 4e db e1 83 e7 b7 2b 97-bf f7 33 c4 1a 64 dc 91   N.....+...3..d..
    0040 - 91 5a 73 a4 6f 38 1f bb-fd d5 3c 42 e0 9c 68 1c   .Zs.o8....<B..h.
    0050 - 92 58 f6 07 59 62 5f fd-fc 64 39 a1 65 3f 30 ed   .X..Yb_..d9.e?0.
    0060 - 91 51 a4 ca ff 77 a6 76-53 52 76 6a 66 17 9c 7e   .Q...w.vSRvjf..~
    0070 - 27 58 79 c9 2c bc fe aa-f4 40 fd c9 af 3d 5b 35   'Xy.,....@...=[5
    0080 - 31 c9 43 14 45 47 95 bf-8f ce d8 a7 44 02 2e be   1.C.EG......D...
    0090 - 0d 5e 7b fa a8 a6 c6 b3-08 41 08 90 cc 3b bb a5   .^{......A...;..
    00a0 - 5d 9d 2c ae 5c ad 9f d1-21 95 79 25 09 3b ee 34   ].,.\...!.y%.;.4
    00b0 - 26 69 fb 46 14 24 ef 7a-42 1d 57 c2 f0 0d e7 a9   &i.F.$.zB.W.....
    00c0 - cf b3 14 2c 08 7a e9 09-f6 cb 65 cc 07 c1 2c ca   ...,.z....e...,.
    00d0 - ce bd 3f 0c 2a 97 63 74-cf 46 78 66 a3 29 4b 39   ..?.*.ct.Fxf.)K9

    Start Time: 1687922167
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: C3BFCE47C4EC0FE85E4F8B1CD58F2BBC2E4DD5E5A58464AE3ECB58B3F95982B1
    Session-ID-ctx: 
    Resumption PSK: 73860F129D1830993ED35508007547A341F8D586864891D22E1A61E719152743C7A5FEFECF38B1C9C9D25CC4B287EB86
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 2a 89 33 cb 28 dd 4e 91-c1 91 69 cd 7d 9e 96 47   *.3.(.N...i.}..G
    0010 - 0c 8e 8f 0e c7 16 a9 f9-e3 21 d6 c8 31 20 33 69   .........!..1 3i
    0020 - 1b 93 46 70 3a bd b2 2c-0b bf 5c dd 8b 93 95 2a   ..Fp:..,..\....*
    0030 - 88 1a e8 6a 04 95 6e 14-71 8b 7c 68 95 0f 28 99   ...j..n.q.|h..(.
    0040 - 28 93 3d 2c d0 f5 03 c7-50 61 6d 9c 90 f5 f0 fd   (.=,....Pam.....
    0050 - 16 9a 8c bc 2c 7c e4 88-3e 11 6b 19 c2 bf 3a a7   ....,|..>.k...:.
    0060 - 9a f7 5c 7c 1f 58 62 67-71 81 be a1 67 71 e6 60   ..\|.Xbgq...gq.`
    0070 - 0b 2e fd 02 3b db 4a e7-e2 1a 4d bc 00 96 62 e8   ....;.J...M...b.
    0080 - 23 f6 76 4b e4 b0 d3 41-50 30 27 af 33 01 01 57   #.vK...AP0'.3..W
    0090 - d9 12 8a 67 f5 5f 1c d3-87 7f d8 78 fc 85 ba 0a   ...g._.....x....
    00a0 - 68 a7 db 5e 4f 45 6d 99-ed cf 3e cc 80 52 2b 0a   h..^OEm...>..R+.
    00b0 - dc ea a7 ad 28 90 a8 58-ed af c5 a6 5c 5f 0e e0   ....(..X....\_..
    00c0 - 47 e4 1a f9 03 92 c9 b0-82 a1 73 31 74 a1 4d 4d   G.........s1t.MM
    00d0 - b1 19 e6 31 8a 36 bc d7-93 28 8d d2 83 45 53 54   ...1.6...(...EST

    Start Time: 1687922167
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready.
* BYE Disconnected for inactivity.
closed

Debian bookworm Running dovecot + exim

Have root
certbot --version 2.1.0

Just moved this from a different server - copied /etc/letsencrypt/ over - might be the problem?
Seeing this in dovecot log (from thunderbird clients):


un 27 22:11:31 imap-login: Debug: SSL: where=0x10, ret=1: before SSL initialization
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: before SSL initialization
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: before SSL initialization
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: before SSL initialization
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read client hello
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write server hello
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write change cipher spec
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 write encrypted extensions
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write certificate
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 write server certificate verify
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write finished
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x10, ret=1: before SSL initialization
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: before SSL initialization
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: before SSL initialization
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: before SSL initialization
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read client hello
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write server hello
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write change cipher spec
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 write encrypted extensions
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write certificate
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 write server certificate verify
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write finished
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL alert: where=0x4004, ret=554: fatal bad certificate
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: error
Jun 27 22:11:31 imap-login: Debug: SSL error: SSL_accept() failed: error:0A000412:SSL routines::sslv3 alert bad certificate: SSL alert number 42
Jun 27 22:11:31 imap-login: Info: Disconnected: Connection closed: SSL_accept() failed: error:0A000412:SSL routines::sslv3 alert bad certificate: SSL alert number 42 (no auth attempts in 0 secs): user=<>, rip=192.168.1.173, lip=192.168.1.200, TLS handshaking: SSL_accept() failed: error:0A000412:SSL routines::sslv3 alert bad certificate: SSL alert number 42, session=<1kvF8Cf/19fAqAGt>
Jun 27 22:11:31 imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data
Jun 27 22:11:31 imap-login: Debug: SSL alert: where=0x4004, ret=554: fatal bad certificate

I'm thinking of blowing away the /etc/letsencrypt folder - reinstalling and starting over?

That leads to questions:
RSA or ECDSA ?
Any problem with TLS_AES_256_GCM_SHA384 for thunderbird/exim/dovecot ?
Should I set ssl_stapling on; ssl_stapling_verify on; ?

Thunderbird 102.12.0

2

From the output of s_client, it looks like you are only sending the leaf certificate (cert.pem) rather than the full certificate chain (fullchain.pem). This can affect the ability of other servers and clients to connect.

From this output:

It looks potentially like you have SSL client authentication enabled. It shouldn't be enabled unless you know what you're doing.

5 Likes
3

Here is what I see with nmap -Pn -p25,80,143,443,465,587,993 smtp.xtronics.com

$ nmap -Pn -p25,80,143,443,465,587,993 smtp.xtronics.com
Starting Nmap 7.80 ( https://nmap.org ) at 2023-06-27 20:33 PDT
Nmap scan report for smtp.xtronics.com (108.243.106.82)
Host is up (0.078s latency).

PORT    STATE    SERVICE
25/tcp  filtered smtp
80/tcp  closed   http
143/tcp closed   imap
443/tcp closed   https
465/tcp open     smtps
587/tcp closed   submission
993/tcp closed   imaps

Nmap done: 1 IP address (1 host up) scanned in 1.51 seconds

Yet for Port 465 it seems like the fullchain is being sent

$ openssl s_client -showcerts -servername smtp.xtronics.com -connect smtp.xtronics.com:465 < /dev/null
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = smtp.xtronics.com
verify return:1
---
Certificate chain
 0 s:CN = smtp.xtronics.com
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 27 08:01:15 2023 GMT; NotAfter: Sep 25 08:01:14 2023 GMT
-----BEGIN CERTIFICATE-----
MIIEJTCCAw2gAwIBAgISBCah7iqFgjKroZqADmIB66/nMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzA2MjcwODAxMTVaFw0yMzA5MjUwODAxMTRaMBwxGjAYBgNVBAMT
EXNtdHAueHRyb25pY3MuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1hYO
1ZTtgl8zU2EBdXuNSemDdtukj9mVN8LHI4g9QEPUub7kjNvysWIgFHUtm/VBDfLD
uq1xvDpN3x/q2R20bKOCAhQwggIQMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUsyNw
YQE2GHDDCWGtqxhXQ9TuTFAwHwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsU
wsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vcjMuby5sZW5j
ci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9yZy8wHAYDVR0R
BBUwE4IRc210cC54dHJvbmljcy5jb20wEwYDVR0gBAwwCjAIBgZngQwBAgEwggEF
BgorBgEEAdZ5AgQCBIH2BIHzAPEAdgC3Pvsk35xNunXyOcW6WPRsXfxCz3qfNcSe
HQmBJe20mQAAAYj8Fe/qAAAEAwBHMEUCIQCs4VOg+Vcg8/eVT8SL2GwKxj/QSnGw
dIJ17a4L297IcwIgGFwLmGv2NpiJKgowG6IHbZ+TOGAg4ZXs/vyCzaaKVcIAdwB6
MoxU2LcttiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYj8FfHsAAAEAwBIMEYC
IQD+8cXMqL2zfjlRl/ZZPKH0rKYxt8ac5zqyMcS8KvcioAIhAPrxeaM9KCQctH57
iDZKz4raywyEtV4IR1y8NcAr+QaPMA0GCSqGSIb3DQEBCwUAA4IBAQBEWIliCfYB
Z1aulr4xMz/wwSJdZCpBhKrFeg/Knb0fQaLREBB8JW38B13a54wyyA00qwJsuloR
ETE9k9KfaLQMd2G3Dfzxz8zwdp1n1sonX5J1Z1B2H7+UXuPnVlrO6I/eQN61Oe4i
eCGr6VAX+TQmedbG1yVz+oZHgXF4DZr1A2xPoaSGjd+VudkC0yGlH8oUMU2USIOC
1Ik7zLausaJNt+SdRWhnhHPIGcRHZuEQm1s1VzYD8qW0Cl6in/30ZKz4cTobwInF
KBbACUKMe8Q2fybglGBZJ7lwpEhvsm6cobGNkElCZvTDAby8zcnIVNOl5oNFXNZ9
zEVqoFAfYxJU
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQCt6CRz9BQ385ueK1coHIe+3LffOJCMbjzmV6B493XC
ov71am72AE8o295ohmxEk7axY/0UEmu/H9LqMZshftEzPLpI9d1537O4/xLxIZpL
wYqGcWlKZmZsj348cL+tKSIG8+TA5oCu4kuPt5l+lAOf00eXfJlII1PoOK5PCm+D
LtFJV4yAdLbaL9A4jXsDcCEbdfIwPPqPrt3aY6vrFk/CjhFLfs8L6P+1dy70sntK
4EwSJQxwjQMpoOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5
bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y
sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ
Xmidf3LWicUGQSk+WT7dJvUkyRGnWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4
FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc
SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql
PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOdwiK1O5tmLOsbdJ1Fu/7xk9TND
TwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
SwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5pZGVudHJ1
c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTEp7Gkeyxx
+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEB
ATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQu
b3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0LmNvbS9E
U1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFHm0WeZ7tuXkAXOACIjIGlj26Ztu
MA0GCSqGSIb3DQEBCwUAA4IBAQAKcwBslm7/DlLQrt2M51oGrS+o44+/yQoDFVDC
5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW
9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG
WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O
he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC
Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----
---
Server certificate
subject=CN = smtp.xtronics.com
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4132 bytes and written 399 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
2 Likes
5

@Bruce5051 SMTP != IMAP. Looks like it's mainly Dovecot being misconfigured.

2 Likes
6

No - It had something to do with a thunderbird update - The errors in the dovecot logs made it look like it was a bad cert - not the reality. I had the same error with a snake-oil cert - but now it is working - had to blow away the thunderbird directory.

I hope this stays around here - the bad cert error in the log will mislead others.

1 Like
7

@Osiris

True; occasionally where there is IMAP there is also SMTP; and one of the OP's focus areas seems to be with Thunderbird. Thus I felt it added potentially relevant information in to solve the OP's issue.
OK?

2 Likes
8

Generally: Yes, it's OK to point this out.
And I do see how, since that was the only open port, that is the only result you could have shown.

But adding some clarity to his point, the two ports may be served by different software using separate configuration files; Done at different times and maybe even by different people.
The gist here is that they are likely more unalike than they are alike.
So, to me, even though it was written to you, it seems like something meant for @xtronics to be made aware of.

2 Likes
9

Ah, yes. When I was a kid and my cousins were over, my Dad would always yell at me even if it was one of my cousins doing the wrong; his method of indirectly talking to my cousins. :crazy_face:

2 Likes
10

That all said, currently there still isn't anything listening on port 143 nor 993, so no IMAP server reachable. Same as what Bruces NMap showed earlier I guess. So no clue if OP indeed fixed their chain problem or not.

4 Likes
11

Thanks for your efforts - dealing with multiple issues (migrating servers - locations - updates to OS), the one that was hard to figure out turns out was totally due to Thunderbird. While you were probing - I was making several changes... fixing exim config and more..

I've seen this called error 42 - from "alert bad certificate: SSL alert number 42" the explanations floating around the web are misleading. What is clear is that >>> The Cert is NOT "bad" <<<<- Thunderbird is rejecting it (very poor wordage in error message.).

If one changes certs - for a local LAN - in this case the LAN is *.network - thus can not be verified - it is possible, but if done in the wrong order seems to mess up Thunderbird in a way that is not easily recoverable. (Trying to view the cert before 'Add Exception' breaks something - I think? This has something to do with the profile/cert_override.txt file). The instructions found for this vary with when it was posted and much of it is just wrong - misleading etc.

Much has changed from when I first set up this Exim system - 20 years ago - and I've grown old.. I need to update the reverse DNS records and run more tests..

Really appreciate your generous and kind efforts - might be more interesting to see what you find with probes next week.

4 Likes
12

I use Let's Encrypt certificates for the hostnames in my network. child zone. You are probably abusing namespace in a valid TLD. It might be time to rename the zone your LAN uses.

3 Likes
13

See:

3 Likes
14

Appendix G in RFC 6762 and RFC 8375 offer some reserved namespaces for use in private networks.

3 Likes
15

I think you both mean the same: OP is using a "real" and public (not listed in RFC 6762/RFC 8375, but is listed in https://data.iana.org/TLD/tlds-alpha-by-domain.txt) TLD for their own private use in their own private network, which generally is a no-no.

3 Likes
16

IMHO, the simplest things work the best and last the longest.

If you want to use .network but you don't want to register a real .network domain...
Simple add an underscore [or dot underscore] to the name:

  • my.lan.server.network_
  • my.lan.server.network._

I'm pretty sure that such names will NEVER conflict with real names and should be handled easily by your DNS system.

2 Likes
17

Or just use one of the proper TLDs from the RFCs.

4 Likes
18

For the ones that RTFM, yes - for everyone else what?
[dot underscore is the way to go]

2 Likes
19

I do like my private TLDs to be kinda easily readable and just an underscore is, IMO, not that :wink:

But we're getting offtopic I believe :slight_smile: (and more about personal style/preferences..)

4 Likes
20

Obviously, you can and do RTFM - stick with what you know.
But, yes, we have drifted far from the shore of this topic.
So, I will also end my discussion on this pinpoint here.

2 Likes
21

@linkp

Thanks - various reasons to have a local TLD - some equipment won't let you use a bare IP.. I started using 'network' many years ago - when TLD were only 3 characters.. They should have set up standardized private TLD a decade or so ago.. If I have to change it - looks like 'lan" or 'intranet'. Part of the problem is the needless explosion of TLD..

They say they don't want people to use them - not sure how DDNS would work?

One thing is clear - the complexity of maintaining a network has exploded over the decades - at some point, we are losing ground.

1 Like