Bonjour,
J'ai depuis des mois des problèmes intermittents d'accès SSL sur mon site, hébergé sur le cluster026 (voir un post précédent sans réponse précise).
Aujourd'hui, j'ai eu la chance de pouvoir caractériser ça sous la forme d'un problème de certificat: La plupart du temps, le serveur renvoie un certificat correct avec le common name du site (tsduck.io). Mais certaines fois, il renvoie un certificat avec le common name du cluster (cluster026.hosting.ovh.net). Et là, évidemment, le client décroche tout de suite.
En gros, les accès en HTTPS fonctionnent la plupart du temps mais, pendant certaines périodes, les accès HTTPS plantent, puis remarchent, puis plantent, etc. Hors de ces périodes d'instabilité, assez fréquentes par ailleurs, ça marche.
Aujourd'hui, je suis dans une période instable. Exemple d'accès qui ne marche pas:
$ curl -sL https://tsduck.io/ >/dev/null --trace-ascii /dev/stderr
== Info: Trying 87.98.154.146:443…
== Info: TCP_NODELAY set
== Info: Connected to tsduck.io (87.98.154.146) port 443 (#0)
== Info: ALPN, offering h2
== Info: ALPN, offering http/1.1
== Info: successfully set certificate verify locations:
== Info: CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
=> Send SSL data, 5 bytes (0x5)
0000: …
== Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
=> Send SSL data, 512 bytes (0x200)
0000: …Zp."…~;:.?..R;.UV…E.. &.f…>…C&.[..u.in
0040: ..~P…>…,.0…+./…$.(.k.#.'.g…9…3…=.
0080: <.5./…u…tsduck.io…3t…
00c0: h2.http/1.1…1….(…
0100: …+…-…3.&.$… ..h.-.i…|..p..e*A…fQN.w4XO..
0140: …
0180: …
01c0: …
== Info: OpenSSL SSL_connect: Connection reset by peer in connection to tsduck.io:443
== Info: Closing connection 0
Or, si je visualise le certificat envoyé par le serveur en utilisant nmap, la même commande me renvoie deux common names différents sur la même adresse à deux minutes d'intervalle (cf. time stamps affichés):
$ nmap -p 443 --script ssl-cert tsduck.io
Starting Nmap 7.91 ( https://nmap.org ) at 2020-11-13 18:16 CET
Nmap scan report for tsduck.io (87.98.154.146)
Host is up (0.032s latency).
rDNS record for 87.98.154.146: cluster026.hosting.ovh.net
PORT STATE SERVICE
443/tcp open https
| ssl-cert: Subject: commonName=cluster026.hosting.ovh.net
| Subject Alternative Name: DNS:cluster026.hosting.ovh.net, DNS:www.cluster026.hosting.ovh.net
| Issuer: commonName=Sectigo RSA Domain Validation Secure Server CA/organizationName=Sectigo Limited/stateOrProvinceName=Greater Manchester/countryName=GB
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2020-06-02T00:00:00
| Not valid after: 2021-06-02T23:59:59
| MD5: 0a85 bbec c768 694a f714 0e7c f0b1 31c8
|_SHA-1: f8db 0946 5ade 6f79 1af3 46e8 a5bd d6fe 532f a117
Nmap done: 1 IP address (1 host up) scanned in 0.57 seconds
$
$ nmap -p 443 --script ssl-cert tsduck.io
Starting Nmap 7.91 ( https://nmap.org ) at 2020-11-13 18:18 CET
Nmap scan report for tsduck.io (87.98.154.146)
Host is up (0.020s latency).
rDNS record for 87.98.154.146: cluster026.hosting.ovh.net
PORT STATE SERVICE
443/tcp open https
| ssl-cert: Subject: commonName=tsduck.io
| Subject Alternative Name: DNS:tsduck.io, DNS:www.tsduck.io
| Issuer: commonName=Let's Encrypt Authority X3/organizationName=Let's Encrypt/countryName=US
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2020-10-22T08:52:30
| Not valid after: 2021-01-20T08:52:30
| MD5: b6cd fdd9 14ea 7bbf 3e39 1670 2858 7d42
|_SHA-1: b50b 0d09 fc11 9706 5fab ad02 a9ff 9ce8 0735 c636
Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
Le premier est un certificat Sectigo valable un an pour OVH. Le deuxième est le certificat Let'S Encrypt normal de mon site, valable trois mois.
Il faudrait vraiment qu'un admin OVH se penche sur le problème. On ne peut pas assurer un hébergement SSL correct si le serveur renvoie de temps en temps un certificat qui n'est pas celui du site hébergé.
Merci de votre aide.
on ne peut pas grand chose pour toi, c'est à Ovh de jouer … 
et c'est bien vu, première fois que c'est signalé ici
un problème de plus pour le cluster26 ou les clusters>=26
si nmap trouve un certificat correct, openssl échoue par contre
```text
echo | openssl s_client -showcerts -servername tsduck.io -connect tsduck.io:443 | openssl x509 -inform pem -noout -text
write:errno=104
unable to load certificate
140568408093760:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
```
on ne peut pas grand chose pour toi, c'est à Ovh de jouer ... :(
Je m'en doute bien. Mais comment demander ça à OVH, à part un message ici? D'habitude, je me débrouille tout seul mais là j'ai besoin du support OVH et comment les contacter?
le support n'est plus ici depuis un moment…
le support n'est plus ici depuis un moment...
OK, mais comment fait-on concrètement pour contacter le support technique OVH quand on a un problème technique assez raisonnablement analysé comme celui-là?
officiellement, support Ovh:
+33.972101007
ou 1007 en France
ou un ticket dans le manager Ovh
mais bon
officiellement, support Ovh:
mais bon :(
Effectivement... Ticket créé depuis 5 jours et rien, pas même un ack quelconque. C'est pourtant probablement un problème tout bête de configuration Apache, peut-être une référence manquante au certificat dans l'entrée du serveur virtuel sur un des noeuds du cluster. Probablement un noeud de backup ou de montée en charge activé périodiquement seulement.
C'est quand même un peu le boulot du support de corriger ce genre de truc.
Sait-on combien de noeuds sont dans le cluster026 et quelle est la politique de maintenance et de continuité pour les noeuds additionnels?
> C'est quand même un peu le boulot du support de corriger ce genre de truc.
clairement, mais il ne doit plus y avoir de techniciens
la bateau sans pilote qui courre sur son erre j'imagine
parfois je vois sortir des réponses alacon de stagiaires sortis d'école sur du Worpdress, mais sur les vrais bugs Ovh… RIEN
de mon côté, en privé, j'ai des clients sans nouvelles, BLOQUÉS, PARFOIS depuis plus d'un mois, avec des commandes de transfert échouées et un support qui ne réponds pas et n'intervient pas
@kyodev, en effet il y a de quoi piquer une crise avec le support OVH. Voici le récit du traitement de ce problème:
Le 13/11, je crée le ticket pour le support, avec un lien vers ce post pour avoir toutes les informations techniques et les tests effectués.
Le 26/11, soit 13 jours après (13…), je reçois "Je constate que vous avez réussi à activer le certificat ssl sur votre tsduck.io, il affiche correctement le contenu". Je relis trois fois pour vérifier que je n'ai pas rêvé. Je réponds "Vous n'avez probablement pas lu avec attention la description du problème etc…" en précisant pourquoi ça n'a rien à voir.
Le 9/12, soit encore exactement 13 jours après, ils sont bien synchrones au support, je reçois "Je vous confirme qu'il n' y a pas aucun souci de notre côté".
Ca existe vraiment des gens comme ça?
Plus ou moins désabusé, j'ai répondu : Pourriez-vous soumettre le problème à quelqu'un qui comprend ce que veut dire "préciser un nom de domaine dans le SNI d'un CLIENT HELLO SSL" et "recevoir en retour un certificat dont le common name est différent du domain name précisé dans le SNI".
Mais bon, je comprends surtout que quand il y a un problème chez OVH, on se le garde pour la vie…
il y a de quoi piquer une crise avec le support OVH
Merci de ton retour.
Pour ton info, @kyodev s'est fait bannir pour un mois car il y a eu quelques prises de tête épiques ici. Encore un truc où tous les protagonistes sont plus ou moins coupables, les uns sur le fond et les autres sur la forme.
J'espère qu'il va survivre à ça, car il était au taquet 24/7/365 (d'ailleurs je ne sais pas quand il dormait)
Maintenant, sincèrement tu ne dois rien attendre du support OVH.
La dernière fois qu'ils sont passés sur le forum c'est pour bannir @kyodev
C'est une honte sans nom.
Octave à qui as-tu vendu ton âme ?