Bonjour
Lorsque je me connecte à mon serveur de mail avec Thunderbird je reçois le message
Certificat de sécurité non valide.
Mais lorsque je teste en ligne de commande:
$ openssl s_client -connect mail.webologix.com:143 -starttls imap -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = webologix.com
issuer=C = US, O = Let's Encrypt, CN = R3
notBefore=Apr 30 21:10:07 2022 GMT
notAfter=Jul 29 21:10:06 2022 GMT
Toute aide bien venue
Bonjour,
Le nom d’hôte de ton serveur e-mail est mail.webologix.com et l’objet de ton certificat est webologix.com, le problème vient peut-être de là.
Il me semble que Thunderbird donne un peu plus de détails si on lui demande…
Liste des certificats inclus:
> egrep -R "ssl_cert|ssl_key|ssl_protocols|ssl_cipher_list" /etc/dovecot | egrep -v "#"
/etc/dovecot/dovecot.conf:ssl_cert = </etc/postfix/smtpd.cert
/etc/dovecot/dovecot.conf:ssl_key = </etc/postfix/smtpd.key
/etc/dovecot/conf.d/10-ssl.conf:ssl_cert = </etc/letsencrypt/live/webologix.com/privkey.pem
/etc/dovecot/conf.d/10-ssl.conf:ssl_key = </etc/letsencrypt/live/webologix.com/fullchain.pem
> ll /etc/postfix/smtpd.cert
lrwxrwxrwx 1 root root 49 31 déc. 10:48 /etc/postfix/smtpd.cert -> /etc/letsencrypt/live/webologix.com/fullchain.pem
> openssl x509 -text < /etc/letsencrypt/live/webologix.com/fullchain.pem|grep DNS
DNS:mail.webologix.com, DNS:webologix.com, DNS:www.webologix.com
Connexion depuis un client:
~$ openssl s_client -connect mail.webologix.com:imaps
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 = webologix.com
verify return:1
---
Certificate chain
0 s:CN = webologix.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFRTCCBC2gAwIBAgISAzs9WstD6t6vdt2eDXGN76anMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMjA0MzAyMTEwMDdaFw0yMjA3MjkyMTEwMDZaMBgxFjAUBgNVBAMT
DXdlYm9sb2dpeC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDY
/DV6QAMmGLAABKrpGIjh4pEHpockv+A3VKpknFebFQe8a15WdsPbybZAOGdRkibm
6bCskkZS6+frjujI52F7ld33i+9gAYKtoc3u059EUT8o64izlF7r9i9sb+l0Oo1R
f2IVV8sFPV8ijAl0nYnCjm42Px4uDLthhLKW3TAQ0UOfnsB2abSaLDFN8fSd9HyI
D3GrI3VpRCvjPjBZtSBj2tts+BJWHuoDy7Q7rlN34rajokuLBueAu77yK0KblJKY
fRggAl8WW1S26UGKkdFE/YIf+zFATeSU8ROzvfFSf/kpTh+5BFvVTc0dndPautmN
11ZcVuhJJVulPcourwm7AgMBAAGjggJtMIICaTAOBgNVHQ8BAf8EBAMCBaAwHQYD
VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0O
BBYEFNWQrxOu00SIxxlb0gVw1Nci3hTUMB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJ
QOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEFBQcwAYYVaHR0cDovL3Iz
Lm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8vcjMuaS5sZW5jci5vcmcv
MD8GA1UdEQQ4MDaCEm1haWwud2Vib2xvZ2l4LmNvbYINd2Vib2xvZ2l4LmNvbYIR
d3d3LndlYm9sb2dpeC5jb20wTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC
3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcw
ggECBgorBgEEAdZ5AgQCBIHzBIHwAO4AdQDfpV6raIJPH2yt7rhfTj5a6s2iEqRq
Xo47EsAgRFwqcwAAAYB8hiP9AAAEAwBGMEQCIEpL0TBl6mlQeBYvNoFVPK1wMTsG
/TX9Guv+9lqR9EhaAiAozfpGB7wzYK8jo+6AxTkUZqNwEWwHr+ljtPXukU5GeAB1
AEalVet1+pEgMLWiiWn0830RLEF0vv1JuIWr8vxw/m1HAAABgHyGJCUAAAQDAEYw
RAIgQu/P8ZjjyaR6yIl9jSWv57BL/pT5rEq3OFffGKo6LMgCIEfxVGBpVr60SJ2u
59CnMHMUFg1l5FSB1u0sa0GcqBYeMA0GCSqGSIb3DQEBCwUAA4IBAQBtIuKfei10
UOzDCL9tjlSEaXmZsFKaS2pJemg2A44niq2jj+dBfKk07Zt/uHq/X8LdgedOOqjT
PjjvGA1iP+YIo3llP7dsSmblE6Xxf5iETU42ljfD3xcgdJmSyWcP0vfJ1/3TfGtx
3WBBOtwIwNRi+plZY+nmdfLyhN04LgfqkRQYhD4jwHbJxvBAcb8qy0ryIIOBK/8d
NOtXTuU/IXZ7mp+mNL5bE2Fq6mDf3mCtDRRz20rtEF5q8KVGdfeG8xur2ZFfReZc
Zh2cOyip5yfIyKxhZP5nL50hYmA9N0Il8AMRM1RLzXIee+3NA9okR8qxzPY6flls
V09Ew4zlY+Uo
-----END CERTIFICATE-----
subject=CN = webologix.com
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4609 bytes and written 390 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 2B659AA105471E4221ACAD50C5542F5C010A9DF54C020BA6DF80BF9943F9033A
Session-ID-ctx:
Resumption PSK: A20F3E1EF94D5364ADD351C606213748B213ED9261912F8D10F9D66DCDE680ED221F3F22490CCE5039035116274AE188
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - cf bc e0 d2 8b 59 2a eb-7b 3a b8 b6 fd 17 56 fc .....Y*.{:....V.
0010 - 60 dd 2a 82 b9 1f 2f b8-ea 1c c0 b4 55 df 50 c4 `.*.../.....U.P.
0020 - 1d 05 92 f9 7b ed 87 1e-a0 58 11 34 79 47 80 1d ....{....X.4yG..
0030 - 23 3f 1f 45 80 a4 84 c4-d4 b0 61 12 9c 65 00 42 #?.E......a..e.B
0040 - 0c 59 77 a8 44 01 db df-02 84 23 bb 1a 93 a6 9b .Yw.D.....#.....
0050 - a0 e9 5c 39 a8 55 df e0-ba 31 16 a7 0e 03 ff a3 ..\9.U...1......
0060 - b7 8e be 46 21 18 ec e8-24 3b 15 15 04 d8 01 0d ...F!...$;......
0070 - 96 30 bd d9 4a 94 b9 c3-b1 94 07 6e 63 c8 d5 48 .0..J......nc..H
0080 - f7 d0 3c e3 0d fc 05 20-11 5b 88 4a ca 53 27 e5 ..<.... .[.J.S'.
0090 - 2b 66 4b dc 7a ce 28 9a-47 4f b1 5b 88 0d 5d dd +fK.z.(.GO.[..].
00a0 - 6c 84 3c e2 fe 27 3c 94-bf 99 02 31 5b 12 95 12 l.<..'<....1[...
00b0 - 23 6f 71 67 95 c2 67 15-70 14 b9 fe 69 35 02 e3 #oqg..g.p...i5..
00c0 - cc 4d 57 22 17 c9 4d 8b-b7 ac d4 85 bb 9d 1c 5f .MW"..M........_
00d0 - 5a b4 9a 02 7c 39 e5 fd-62 3f ed ca f4 3d 3b 44 Z...|9..b?...=;D
Start Time: 1656149927
Timeout : 7200 (sec)
Verify return code: 0 (ok)
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: A69D0C838C7D5DBA71082C807E284F8A21CF89037ADFF23CE8202CC14D0BDB30
Session-ID-ctx:
Resumption PSK: 9DDBF6044BE9BB70FB8A7E6434B0BD04216AAA6E32DADE0B7F55DC98DC84B87378FB9CE5A4670004B9518E41ABAB4796
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - cf bc e0 d2 8b 59 2a eb-7b 3a b8 b6 fd 17 56 fc .....Y*.{:....V.
0010 - 07 f5 64 f0 a5 f4 6e 6b-aa 0e f4 9e 97 62 78 79 ..d...nk.....bxy
0020 - 7c fb bc 22 6a 71 06 43-f1 d2 58 7a ab 48 59 90 |.."jq.C..Xz.HY.
0030 - 79 b9 75 07 b9 63 6a 9e-c1 04 16 a4 e3 f8 22 dc y.u..cj.......".
0040 - 39 c7 e5 67 6e d6 a4 12-e2 26 75 2a 2a 78 56 69 9..gn....&u**xVi
0050 - f0 dc 4f c7 4c a0 61 d7-ec f3 c9 11 87 d7 a2 37 ..O.L.a........7
0060 - 72 86 a6 23 e2 a7 a6 24-2f d1 18 4e 80 80 7b 6f r..#...$/..N..{o
0070 - a5 60 33 06 82 db b5 5f-16 ef 11 9b f0 45 8c 17 .`3...._.....E..
0080 - 74 4e 80 fd dc 0d b7 04-53 bb 02 da ec 65 1b 49 tN......S....e.I
0090 - c5 ae 9a 5b 42 c3 88 1b-a5 aa 7e cb 04 bb 34 20 ...[B.....~...4
00a0 - 06 1c c2 be b9 40 51 a5-04 23 de 7e c5 42 82 ec .....@Q..#.~.B..
00b0 - 81 23 6b 8b ff 15 ea d7-d5 01 bf d9 df b2 41 53 .#k...........AS
00c0 - 04 da 03 0a 1c c4 30 fd-7c b5 14 0e 68 8f 70 14 ......0.|...h.p.
00d0 - 95 29 0f 6c 2c ba 44 b9-f6 12 b5 f2 f5 41 90 cf .).l,.D......A..
Start Time: 1656149927
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot (Debian) ready.
Ah, au temps pour moi, mon client e-mail ne me donne pas d’erreur, je pense que le problème vient de tes clients e-mail.
Si j’utilise « ks307144.kimsufi.com » comme nom de serveur l’avertissement de sécurité de Thunderbird semble disparaitre.
Un doute me viens au sujet des hostname:
> cat /etc/postfix/helo_access
/^ks307144\.kimsufi\.com$/ REJECT
/^\[?94\.27\.227\.123\]?$/ REJECT
/^webologix\.com$/ REJECT
/^mail\.webologix\.com$/ REJECT
> cat /etc/hosts
127.0.0.1 webologix.com
127.0.0.1 localhost
127.0.1.1 ks307144.kimsufi.com ks307144
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
94.23.227.123 ks307144.kimsufi.com ks307144
> cat /etc/postfix/main.cf
smtpd_banner = $myhostname ESMTP $mail_name
...
myhostname = webologix.com
...
ks307144.kimsufi.com ne fait pas partie du certificat webologix.com. Serait-ce le pb ?
L’ordre d’apparition de myhostname dans main.cf a-t-il de l’importance ?
Ah, essaie un truc : ferme thunderbird, puis déplace sa configuration dans un autre dossier (un truc du genre mv ~/.thunderbird ~/.thunderbird.old), puis relance-le et reconfigure ta boîte avec le nom d’hôte mail.webologix.com.
Ensuite, tu nous donnes l’erreur exacte retournée par Thunderbird, avec tous les détails que celui-ci accepte de bien vouloir te donner.
Vérifie que ta machine est bien à l’heure.
Il peux aussi allez purger l’ancien certificat dans Thunderbird dans les préférences / vie privée et sécurité, tous en bas il y a la gestion des certificats.
Par contre il faut faire attention à une chose, le certificat en question est-il bien pris en charge par Postfix ? il ne faut pas confondre le certificat qui sert un éventuel webmail de celui qui est utilisé pour l’envoi de mail …
Quel est la configuration de postfix (côté SSL bien entendu) ?
Il vient effectivement de là, le common name est inconsistant entre le serveur et le certificat. Tu aurais du soit utiliser un certificat avec wildcard (*.webologix.com) soit un certificat specifique au serveur avec le common name à mail.webologix.com
Let’s encrypt ne permet pas ce genre de substilité.
Personnellement, je préfère faire comme ça, mais il semble que ce soit une erreur de la part des client que j’ai utilisés, en fait, le certificat utilisé s’applique, en plus de webologix.com, à www.webologix.com et mail.webologix.com.
Si c’est marqué la dedans, mais il y a une procédure à suivre semble-t-il.
Ce n’est pas normal, il doit y avoir quelque chose qui soit n’est pas activé (vérification serveur certificat). normalement un certificat toto.duchmol.com ne peux pas servir à memere@duchmol.com, du moins sans erreur.
Oui, c’est un certificat de nom de domaine, pas un certificat d’adresse e-mail.
Ca ne change rien, c’est le même principe pour un certificat client.
ceci dit, dans les commandes montrées par
C’est un certificat server qui est montré dans ce que présente le server au client.
Normallement tu as deux niveau de certification dans un échange de ce type:
Client —>serveur
CA Chain sur le Client vérifie le certificat server (certificat host)
Client <—serveur
Le CA Chain du serveur vérifie le certificat client (certificat user)
Ayant rencontré des problèmes de reverse DNS sur mail.webologix.com je suis revenu sur le FQDN original du serveur ks307144. J’ai modifié myhostname et certificats SSL dans Postfix et Dovecot en conséquence.
Voici les éléments de configuration:
> rgrep -i TLS /etc/postfix/main.cf
/etc/postfix/main.cf:smtpd_tls_cert_file = /etc/postfix/smtpd.cert
/etc/postfix/main.cf:smtpd_tls_key_file = /etc/postfix/smtpd.key
/etc/postfix/main.cf:smtpd_use_tls = yes
/etc/postfix/main.cf:smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
/etc/postfix/main.cf:smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
/etc/postfix/main.cf:smtpd_tls_security_level = may
/etc/postfix/main.cf:smtpd_tls_received_header = yes
/etc/postfix/main.cf:smtpd_tls_auth_only = no
/etc/postfix/main.cf:smtpd_tls_loglevel = 1
/etc/postfix/main.cf:smtp_tls_note_starttls_offer = yes
/etc/postfix/main.cf:smtpd_tls_session_cache_timeout = 3600s
/etc/postfix/main.cf:smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
/etc/postfix/main.cf:smtp_tls_security_level = may
/etc/postfix/main.cf:smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
/etc/postfix/main.cf:smtpd_tls_protocols = !SSLv2,!SSLv3
/etc/postfix/main.cf:smtp_tls_protocols = !SSLv2,!SSLv3
/etc/postfix/main.cf:smtpd_tls_exclude_ciphers = RC4, aNULL
/etc/postfix/main.cf:smtp_tls_exclude_ciphers = RC4, aNULL
/etc/postfix/main.cf:smtp_tls_loglevel = 1
/etc/postfix/main.cf:tls_ssl_options = NO_COMPRESSION
/etc/postfix/main.cf:smtpd_tls_mandatory_ciphers = high
/etc/postfix/main.cf:tls_high_cipherlist = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
/etc/postfix/main.cf:smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
/etc/postfix/main.cf:smtpd_tls_dh1024_param_file = /opt/Certbot/certbot/ssl-dhparams.pem
/etc/postfix/main.cf:#smtpd_tls_dh1024_param_file = /etc/ssl/private/dhparams.pem
/etc/postfix/main.cf:smtp_use_tls = yes
> ll /etc/postfix/smtpd.cert
lrwxrwxrwx 1 root root 56 25 juin 16:28 /etc/postfix/smtpd.cert -> /etc/letsencrypt/live/ks307144.kimsufi.com/fullchain.pem
ks307144 kmc > openssl x509 -text < /etc/letsencrypt/live/ks307144.kimsufi.com/cert.pem|grep DNS
DNS:ks307144.kimsufi.com, DNS:webologix.com
> rgrep -i _cert /etc/dovecot/
/etc/dovecot/dovecot.conf:ssl_cert = </etc/postfix/smtpd.cert
/etc/dovecot/conf.d/10-ssl.conf:ssl_cert = </etc/letsencrypt/live/webologix.com/privkey.pem
Je n’utilise pas de certificat coté client pour le moment
En utilisantun thunderbirdsur un autre ordi, voici le message obtenu:
peux tu afficher le détail du certificat?
Ton Thunderbird ne dispose pas du certificat Root CA qui a fournit le certificat serveur, il ne peut donc pas le vérifier.
Toute machine qui devra utiliser ce serveur doit avoir le CA qui a fourni le certificat serveur pour le vérifier, sinon tu auras toujours l’erreur.
Afficher le détail est un peu compliqué car il faut cliquer sur chaque rubrique. Voulez-vous voir une rubrique particulière ?
Comment je retrouve et mets le CA en question sur le serveur et le client ?
Ca veut dire que si je fournis plusieurs domaine mails à des clients il faut que je leur demande de mettre ce certificat dans leur client ?!!!
Avec Let’sEncrypt tu as un fichier de certificat contenat la chîne complète de certification (donc y compris le certificat de l’AC) qui se nomme fullchain.pem. C’est celui-là que tu doit indiquer dans la configuration de tes serveurs et non cert.pem
Exemple avec Dovecot :
ssl_cert = </etc/letsencrypt/live/example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/example.com/privkey.pem
Mon message à surement du passer à la trappe … montre nous la configuration postfix de ton serveur mail (en particulier la partie certificat).
Si comme tu le dit lorsque tu configure la partie en ksXXXXX.kimsufi.com l’authentification ne crie pas au scandale c’est que tu n’utilise pas le bon certificat dans ta configuration postfix.
En particulier cette partie (mais pas que) :
smtpd_tls_key_file =
smtpd_tls_cert_file =
smtpd_tls_CAfile =
Après c’est lors de l’envoi d’un mail ce message ou lors de la configuration de l’adresse ?
De plus ta zone DNS n’est pas académique, tu la gèe depuis OVH ? si oui regarde leur documentation il a des trucs pas très académiques SOA, NS, SPF.
+1
Et d’après mon précédent message pour Postfix :
smtpd_tls_cert_file = /etc/letsencrypt/live/example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/example.com/privkey.pem
smtpd_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
le CA est lié à let’s encrypt normallement si c’est eux qui ont fourni le certificat.
Si tu as un certificat chainé, le contenu de la chaine est exportable (une chaine c’est Root CA → Sub CA → Certificat final).
Tu devrais pouvoir le faire avec openssl (mais je ne connais plus les commandes).
Tu dois peut etre le voir dans l’(onglet detail), dont je parlais dans mon message précédent.
Typiquement, Let’Encrypt R3 est normallement le CA qui a fourni ton certificat, donc c’est celui là qui doit etre intégré dans ton thunderbold.
Si tu vas dans Paramètre, vie privée et securité, Afficher les certificat, normalement tu dois avoir dans l’onglet Autorité une entrée concernant Let’s encrypt.
l’explication normalement st ici: Chain of Trust - Let's Encrypt
Il n’y a rien à intégrer dans le client. L’autorité de certification parente ISRG est déjà intégré de base partout. Si ce n’était pas le cas utilisation des certificats Let’sEncrypt perdrait beaucoup de son intérêt.
C’est au niveau du serveur qu’il y a un problème de configuration.