PRIVATE EXCHANGE 2019 - Nouveau certificat qui pose problème
... / PRIVATE EXCHANGE 2019 - N...
< Previous question   -   Next question >
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Question

PRIVATE EXCHANGE 2019 - Nouveau certificat qui pose problème

C
by
CK
Created on 2025-06-25 15:16:19 (edited on 2025-07-09 09:09:24) in Hosted Exchange

Bonjour,
début JUIN nous avons cliqué sur le bouton pour renouveler le certificat SSL de noter messagerie Exchange.
Lorsque le certificat a été mis en place, l'outil en ligne de commande sous windows (SendEmail.exe) que nous utilisons dans nos batchs pour envoyer un mail a certaines personnse pour leur confirmer que le batch s'est bien déroulé  ne fonctionnaient plus...

Les personnes équipés d'iphone 7, ne pouvaient plus recevoir de mail, "erreur problème de certificat".
plus de mises a jour disponible pour ces iphone là.

Les personnes équipées d'iphone 11, idem. Mais une mise a jour vers la dernière version d'IOS a pu régler le probleme. Suite a cela, les boites mails etaient de nouveau fonctionnelles.

sur un serveur web sous debian stable, a jour, avec PHP_mailer il n'etait plus possible d'envoyer de mail en interne, idem probleme de certificat.

Lorsque j'ai fait mon diagnostique en passant par differents sites de tests, le bilan a indiqué parfois que tout allait bien, et parfois qu'il manquait un certificat intermediaire dans la chaine de certificat.

J'ai ouvert un ticket chez OVH en leur exposant le problème avec ce certificat, mais après 15 jours a me battre avec eux j'ai du abandonner. ils ne veulent rien savoir, tous leurs tests prouvnet que le certificat n'a pas de probleme malgré tous les cas de figure ou je leur ai démontré que cela ne fonctionnait pas.

Le domaine est le suivant : image

Je copie/colle un bout de discussion avec chatgpt pour solutionner le probleme, OVH n'en a pas tenu compte.

image

Comme je l'ai dit, pour OVH le certificat est bon, et grosso modo a nous de nous adapter avec des outils "qui marchent".

J'ai donc fini par trouver comment contourner le probleme avec un aute outil en ligne de commande mailsend-go.exe https://github.com/muquit/mailsend-go qui par defaut ne teste pas le certificat, donc ca marche, si on active la verification du certificat avec l'argument (-verifyCert = Verify Certificate in connection. Default is No) et bien cela ne marche pas. On a donc remplacer toutes nos commandes SendEmail par celle-ci.

Pour la parti web avec PHP_mailer nous avons trouvé le petit bout de code qui permet de désactiver là aussi la verification du certificat. Comme les mesures de contournement ont été trouvées, j'ai décidé d'arreter de me prendre la tete avec OVH.

MAIS !!!!!!!!! aujourd'hui je suis confronté a un nouveau problème. Nous souhaitons utiliser https://www.leexi.ai/ dans Teams, et pour paramétrer la connexion avec noter Exchange il y a une procédure qui consiste à rattacher un compte mail a leur interface client pour récupérer le calendrier de l'utilisateur. et là ca ne marche pas : Erreur SSL, problème de certificat...

Donc selon vous est-ce que mon serveur exchange a un probleme de certificat oui ou non ???
Upvotes (0)
3288 Views
11 Replies ( Latest reply on 2025-07-09 09:09:24 by
CK
)

Bonjour,

Il me semble que vous avez été faire des tests via SSLlabs car il y avait des résultats en cache, tout frais.

Je suis perplexe.

Tout d'abord SSLLabs ne fait des tests que sur le port 443 (donc ni SMTP, ni IMAP ou autre) et OVH peut avoir configuré différemment les certificate chains dans les différents services.

Ensuite le " Sectigo Public Server Authentication Root R46 " qui n'est pas fourni par le serveur, mais devait-il l'être ? et pourquoi Path #1, #2, #3 et que seuls #2 et #3 nécessitent un download complémentaire...

J'ai donc lancé testssl sur le serveur SMTP, port 587, avec starttls: (il y a du rouge !)

# ./testssl.sh -t smtp mail.jallatteXfr:587

###########################################################
    testssl.sh       3.0.8 from https://testssl.sh/
    (abdd51d 2022-09-28 09:19:37)

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-bad (1.0.2k-dev)" [~183 ciphers]
 on k3:./bin/openssl.Linux.x86_64
 (built: "Sep  1 14:03:44 2022", platform: "linux-x86_64")


 Start 2025-06-25 15:53:20        -->> 141.95.128X105:587 (mail.jallatteXfr) <<--

 Further IP addresses:   2001:41d0:11b:2f00::8d5fX8069
 rDNS (141.95.128.105):  mail.jallatteXfr.
 Service set:            STARTTLS via SMTP

 Testing protocols via sockets

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      not offered
 TLS 1.1    not offered
 TLS 1.2    offered (OK)
 TLS 1.3    not offered and downgraded to a weaker protocol

 Testing cipher categories

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    not offered (OK)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)       not offered (OK)
 Triple DES Ciphers / IDEA                     not offered
 Obsolete CBC ciphers (AES, ARIA etc.)         offered
 Strong encryption (AEAD ciphers)              offered (OK)


 Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4

 PFS is offered (OK)          ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-GCM-SHA256
                              ECDHE-RSA-AES128-SHA256
 Elliptic curves offered:     prime256v1 secp384r1


 Testing server preferences

 Has server cipher order?     yes (OK)
 Negotiated protocol          TLSv1.2
 Negotiated cipher            ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Cipher order
    TLSv1.2:   ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256


 Testing server defaults (Server Hello)

 TLS extensions (standard)    "status request/#5" "renegotiation info/#65281" "extended master secret/#23"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: no
 TLS clock skew               -3 sec from localtime
 Signature Algorithm          SHA384 with RSA
 Server key size              RSA 4096 bits
 Server key usage             Digital Signature, Key Encipherment
 Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
 Serial                       947613F74B0EA4D6465D2C41B746EBBB (OK: length 16)
 Fingerprints                 SHA1 70700F9FD36ADF0A7ABD470D89E9FDFF03461B6A
                              SHA256 1F9E552284E8490D5875CB5826BA0F68BB9B8BDD75228A2F46532431D49680B7
 Common Name (CN)             mail.jallatteXfr
 subjectAltName (SAN)         mail.jallatteXfr www.mail.jallatteXfr
 Issuer                       Sectigo Public Server Authentication CA DV R36 (Sectigo Limited from GB)
 Trust (hostname)             Ok via SAN (same w/o SNI)
 Chain of trust               NOT ok (chain incomplete)
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   346 >= 60 days (2025-06-06 00:00 --> 2026-06-06 23:59)
 # of certificates provided   2
 Certificate Revocation List  --
 OCSP URI                     http://ocsp.sectigo.com
 OCSP stapling                offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    available - please check for match with "Issuer" above
                              issue=comodoca.com, issue=letsencrypt.org
 Certificate Transparency     yes (certificate extension)


 Testing vulnerabilities

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 ROBOT                                     Server does not support any cipher suites that use RSA key transport
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     not vulnerable (OK)
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK) (not using HTTP anyway)
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK), no SSLv3 support
 TLS_FALLBACK_SCSV (RFC 7507)              No fallback possible (OK), no protocol below TLS 1.2 offered
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://search.censys.io/search?resource=hosts&virtual_hosts=INCLUDE&q=1F9E552284E8490D5875CB5826BA0F68BB9B8BDD75228A2F46532431D49680B7
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     not vulnerable (OK), no SSL3 or TLS1
 LUCKY13 (CVE-2013-0169), experimental     potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 384   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 xc028   ECDHE-RSA-AES256-SHA384           ECDH 384   AES         256      TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 256   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 xc027   ECDHE-RSA-AES128-SHA256           ECDH 256   AES         128      TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256


 Running client simulations via sockets

 Android 8.1 (native)         TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Android 9.0 (native)         TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Android 10.0 (native)        TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Android 11 (native)          TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Android 12 (native)          TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Java 7u25                    No connection
 Java 8u161                   TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Java 11.0.2 (OpenJDK)        TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Java 17.0.3 (OpenJDK)        TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 go 1.17.8                    TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 LibreSSL 2.8.3 (Apple)       TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 OpenSSL 1.0.2e               TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 OpenSSL 1.1.0l (Debian)      TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 OpenSSL 1.1.1d (Debian)      TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 OpenSSL 3.0.3 (git)          TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Apple Mail (16.0)            TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Thunderbird (91.9)           TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)

 Done 2025-06-25 15:54:48 [  97s] -->> 141.95.128.105:587 (mail.jallatteXfr) <<--
Helpful (1)
C

Merci @fritz2cat 🇧🇪 🇪🇺  

C'est bien ce qu'il me semble aussi. sur SSLLABS il y avait du orange si on deploie certaines zones des resultats, avec indiqué "Extra download"

D'autres site ou j'ai fait des tests et qui affichent du "rouge" aussi :
https://httpcs.com/
https://tbs-certificates

J'ai envoyé ces résultats à OVH pour appuyer ma demande, mais pour eux "le résultat n'est pas fiable, ca pourrait etre un faux positif" et ils restent campés sur leur position.
Helpful (0)
C

j'aurai bien aimé savoir s'il y a d'autres serveurs exchange OVH, avec un certificat renouvelé récemment pour vérifier si eux ont bien la chaine de certificat complète ou pas. je ne dois pas être le seul a avoir ce probleme ce n'est pas possible...
Helpful (0)
C

En voici un autre dont le certicat date de septembre 2024, plus ancien donc pas renouvelé récemment, et toujours délivré par SECTIGO. A mon avis mon certificat devait etre concu de la meme manière. il y a un code d'erreur tout de meme mais il ne devait pas etre génant, ou provoqué le type de probleme que j'ai maintenant.
Helpful (0)
C

on voit bien qu'il y a indiqué un certificat Racine + Intermediaire + Entité finale contrairement à mon certificat
Helpful (0)

Je confirme: pour urban conseil, c'est OK

TLS clock skew               -3 sec from localtime
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 4096 bits
 Server key usage             Digital Signature, Key Encipherment
 Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
 Serial                       1659F49FC99F702D17938B8A7EF384CE (OK: length 16)
 Fingerprints                 SHA1 ACCB0B193776B3A9794F4F343D5FC98050480C83
                              SHA256 67275CC1CF106E9EF50E2A95BFA431652347F338E05467946C57F29395236AE8
 Common Name (CN)             exchange.urbanconseilXcom
 subjectAltName (SAN)         exchange.urbanconseilXcom www.exchange.urbanconseilXcom
 Issuer                       Sectigo RSA Domain Validation Secure Server CA (Sectigo Limited from GB)
 Trust (hostname)             Ok via SAN (same w/o SNI)
 Chain of trust               Ok
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   86 >= 60 days (2024-09-19 00:00 --> 2025-09-19 23:59)
 # of certificates provided   2
 Certificate Revocation List  --
 OCSP URI                     http://ocsp.sectigo.com
 OCSP stapling                offered, not revoked
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     yes (certificate extension)

 

tandis que pour kare fil

 Signature Algorithm          SHA384 with RSA
 Server key size              RSA 4096 bits
 Server key usage             Digital Signature, Key Encipherment
 Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
 Serial                       CDAA3F5D2ACF08649B97AFA60EBC0C79 (OK: length 16)
 Fingerprints                 SHA1 5747FD13C061D67B0DFFBC48A0F71B593E8D8206
                              SHA256 E72A3CB6B120F6983412425406FCAA49C4D1A2F7A6536B4E62049C8590C1D179
 Common Name (CN)             ex.karefilXfr
 subjectAltName (SAN)         ex.karefilXfr www.ex.karefilXfr
 Issuer                       Sectigo Public Server Authentication CA DV R36 (Sectigo Limited from GB)
 Trust (hostname)             Ok via SAN (same w/o SNI)
 Chain of trust               NOT ok (chain incomplete)
 EV cert (experimental)       no
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   343 >= 60 days (2025-06-03 00:00 --> 2026-06-03 23:59)
 # of certificates provided   2
 Certificate Revocation List  --
 OCSP URI                     http://ocsp.sectigo.com
 OCSP stapling                offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     yes (certificate extension)

Clairement la trust chain a changé chez Sectigo et OVH n'a pas mis à jour. J'ignore si les certificats intermédiaires devenus inutiles sont toujours présentés par le serveur Exchange.

 
Helpful (1)
C

"et OVH n'a pas mis à jour."

OVH est censé faire quelque chose à son niveau ?

Comment est-ce que je peux faire remonter ce problème vers des gens compétents chez OVH, j'imagine que personne ne nous lit ici...
Helpful (0)

Quand on publie un certificat, c'est une bonne pratique d'inclure toute la chaîne de certificats jusqu'au "root certificate", ce dernier se trouvant dans le navigateur ou ton logiciel client.

C'est pour cela que les durées de vie des root certificates sont très longues (de l'ordre de 30 ans)

Sinon le client doit aller chercher les certificats intermédiaires, et ça plante si on n'est pas connecté.

 
Helpful (1)
C

j'ai installé l'outil que tu utilises pour faire le test, sur mon windows 11 avec WSL. j'ai installé la dernière version 3.2.1 en ligne, plus récente que la tienne. Et voici ce que j'obtiens pour la chain of trust, il y a un detail supplémentaire :

OK: Mozilla Microsoft Apple

Cela explique peut etre pourquoi ça ne pose aucun probleme pour Outlook, et les iphones avec un IOS récent...

 

 
Helpful (1)
C

Explication par chatGPT du "pourquoi Outlook sous windows marche bien, et pourquoi les outils basés sur linux ont un problème" :
Helpful (1)
C

@fritz2cat 🇧🇪 🇪🇺  
Le support Leexi.ai nous a contacté et ont réglé le souci de leur côté, en m'indiquant ceci :

C'est bon de notre côté, nous avons réglé le problème.

La raison du souci c'est que votre certificat a été généré par une autorité créée récemment, dont notre serveur n'avait pas connaissance. Nous avons mis à jour la liste des autorités reconnues par notre serveur. Les autres services que vous utilisez utilisent rencontrent très probablement le même problème. Le problème est maintenant résolu chez nous, et l'intégration a pu être activée.  

Bien à vous,
Helpful (1)

Join discussion