# Site https inaccessible

**URL:** <https://www.debian-fr.org/t/site-https-inaccessible/91236>\
**Category:** Support Debian\
**Tags:** apache\
**Created:** [Juin 7, 2025, 8:54 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236 "2025-06-07T08:54:21Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\
**Post date:** [Juin 7, 2025, 8:54 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/1 "2025-06-07T08:54:21Z")

</div>

Je patauge dans une config https

J’ai un host auto-hébergé (lxc proxmox) avec un serveur apache opérationnel et un vhost en 443 sur es0 ou es1.mon.domaine

\<VirtualHost \*:443\>  
ServerName es1.mon.domaine  
ServerAlias es0.mon.domaine

…

Quand je renseigne es0.mon.domaine dans le /etc/hosts de mon client j’accède bien à [https://es0.mon.domaine](https://es0.mon.domaine).  
Mes certificats sont donc Ok.

J’ai mis à jour es1 en cname dans le dns de mon.domaine et transféré le port 443 sur ma box vers le lxc hébergeant le site.

ping es1.mon.domaine fonctionne bien

mais je n’accède pas (timeout) à [https://es1.mon.domaine](https://es1.mon.domain)

Quand je regarde avec tcpdump je n’ai rien qui sort de mon client qaund je rafraichit le lien précédent !

par ailleurs telnet es1.mon.domaine 443 ne retourne rien également

Je ne comprends pas … et surtout pourquoi le ne vois rien sortir de mon client avec cette commande :  
sudo tcpdump -l -i any host \<ip\_publique de mon serveur\>and (port 80 or port 443) | grep -v «&nbsp;sackOK&nbsp;»

Je suis preneur de toute idée de test complémentaire …

Merci d’avance.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juin 7, 2025, 10:16 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/2 "2025-06-07T10:16:49Z")

</div>

> [@PmGs](#):
>
> \<VirtualHost \*:443\>  
> ServerName es1.mon.domaine  
> ServerAlias es0.mon.domaine

Pas de VirtualAlias dans un vhost. Tu fait deux vhost ou tu fait un redirect.  
ServerAlias c’est pour une conf-available, les vhost c’est pour des sites-availables. En plus, Avec tes certificats, ça n’ira pas.. Si tua s des certificats es1 ils ne seront pas valables pour es0.

Par ailleurs, il faut aller voir dans les fichiers de logs access et error dans `/var/log/apache`.

Quelle est ta configuration complète?

---

<div class="post-metadata">

**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\
**Post date:** [Juin 7, 2025, 10:36 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/3 "2025-06-07T10:36:55Z")

</div>

Hello @Zargos , merci pour ta réponse.

Pour les alias je comprends pas, j’ai toujours fait comme cela …  
Pour les certificats j’ai utilisé -d mon.domaine -d \*.mon.domaine ce qui devrait convenir pour tous les sous-domaines.

Je n’ai rien de spécial dans les fichiers de logs!

Ma conf est basique  
\<VirtualHost \*:443\>  
ServerName es1.mon.domaine  
ServerAlias es0.mon.domaine  
DocumentRoot /var/www/html/Es1

```
    SSLEngine on
    SSLCertificateFile /etc/ssl/mon.domaine/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/mon.domaine/privkey.pem

    <Directory /var/www/html/Es1>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error_ssl.log
    CustomLog ${APACHE_LOG_DIR}/access_ssl.log combined
</VirtualHost>
```

---

<div class="post-metadata">

**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\
**Post date:** [Juin 7, 2025, 10:47 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/4 "2025-06-07T10:47:11Z")

</div>

Par ailleurs, il faut aller voir dans les fichiers de logs access et error dans `/var/log/apache` .

Je regardais dans /var/log/apache2/error.log et pas dans error\_ssl.log où j’ai  
server certificate does NOT include an ID which matches the server name

ce que je ne comprends pas à chaud avec mo -d \*. mais c’est enfin une vraie piste 🙂

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juin 7, 2025, 11:38 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/5 "2025-06-07T11:38:54Z")

</div>

à quoi correspond ton option `-d` ?

Si c’est une option de lancement de apache2 elle ne sert à rien car tu as le fichier de configuration dans `sites-avalable` (activé avec `e2ensite`).

Pour taconf, je te conseille de faire des fichiers de logs spécifique à ton site, comme ça c’est plus facile de s’y retrouver (c’est ce que je fais, access et error sont de l’apache de base, et sinon pour site c’est access-site.log et error-site.log).

Normalement pour l’utilisation de l’alias:

```auto
<VirtualHost *:443>
  ServerName es0.mon.domaine
  ServerAlias es1.mon.domaine

  Redirect "/" "http://es1.mon.domaine/"
</VirtualHost>

<VirtualHost *:443>
  ServerName es1.mon.domaine
</VirtualHost>

```

Vérifie ton certificat avec

```auto
openssl x509 -in /etc/ssl/certs//etc/ssl/mon.domaine/fullchain.pem -text -noout

```

Ceci dit tu ne devrait pas avoir un fullchain pour la configuration d’un site. Tu n’a besoin que du certificat ssl du site. Le reste de la chaine c’est ton navigateur qui va l’utiliser.  
L’utilisation du fournisseur du certificat c’est éventuellement pour vérifier un certificat utilisateur, mais la configuration est différente.

Ton certificat dois avoir les extensions:

```auto
X509v3 extensions:
            X509v3 Authority Key Identifier: 
               ******La clef d'autorité du certificat CA******
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                *********
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
            X509v3 Extended Key Usage: critical
                TLS Web Server Authentication, (TLS Web Client Authentication accessoirement)
            X509v3 Subject Alternative Name: 
                DNS:*.mon.domaine

```

Sachant que le CN du certificat est es1.mon.domaine.

---

<div class="post-metadata">

**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\
**Post date:** [Juin 7, 2025, 1:17 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/6 "2025-06-07T13:17:56Z")

</div>

J’ai un moment cru mon problème résolu car je regardais effectivement dans le mauvais fichier de log mais les logs étaient anciens.

Je repends doucement les points que tu suggères.

> [@Zargos](#):
>
> à quoi correspond ton option `-d` ?

C’est l’option que j’ai utilisée pour créer mon certificat  
` acme.sh --issue --dns -d mon.domaine -d *.mon.domaine`

> [@Zargos](#):
>
> Pour taconf, je te conseille de faire des fichiers de logs spécifique à ton site,

Oui

> [@Zargos](#):
>
> Normalement pour l’utilisation de l’alias:

Petite coquille dans ta redirection http → https mais je ne vois pas (encore) pourquoi ma conf est incorrecte …

> [@Zargos](#):
>
> Vérifie ton certificat avec

a priori Ok, car déjà testé via les test en dns local  
et ces extrait :  
Validity  
Not Before: Jun 2 00:00:00 2025 GMT  
Not After : Aug 31 23:59:59 2025 GMT  
…  
DNS:mon.domaine, DNS:\*.mon.domaine

> [@Zargos](#):
>
> Ceci dit tu ne devrait pas avoir un fullchain pour la configuration d’un site.

C’est superflu effectivement, mais c’est fourni en base par acme.sh, et sauf erreur de ma part ce n’est pas dommageable.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juin 7, 2025, 1:46 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/7 "2025-06-07T13:46:38Z")

</div>

le bout de conf que j’ai mis sort directement de la doc apache.

C’est un certificat let’s encrypt, je ne sais pas comment il marchez. mais fait la vérification oppenssl que je t’ai donné& comme ça tu auras les infos de ton certif.

---

<div class="post-metadata">

**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\
**Post date:** [Juin 7, 2025, 2:05 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/8 "2025-06-07T14:05:25Z")

</div>

> [@Zargos](#):
>
> le bout de conf que j’ai mis sort directement de la doc apache.

Je viens d’essayer to conf, j’ai toujours le même pb et je n’arrive toujours pas à comprendre pourquoi je n’ai rien en sortie de mon client. J’ai également essayé sur mon smartphone, sans wifi, donc sans être connecté à ma box et j’ai également un timeout!

Par ailleurs j’ai relu la doc Apache et je pense que ma conf est correcte également

extrait de ce lien https://httpd.apache.org/docs/2.4/mod/core.html#serveralias

> La recherche du serveur virtuel à base de nom correspondant au plus près à la requête s’effectue selon l’ordre d’apparition des directives `<virtualhost>` dans le fichier de configuration. Le premier serveur virtuel dont le `ServerName` ou le `ServerAlias` correspond est choisi

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juin 7, 2025, 2:43 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/9 "2025-06-07T14:43:53Z")

</div>

Aucun filtrage sur les hosts (IP) et DNS names?  
C’est étonnant que n’ai rien dans les logs.

Essaye de voir en faisant 2 virtual hosts, sans alias.  
Normalement c’est la même configuration, sauf le ServerName.  
Ça te permettra de voir si déjà sous cette forme ça marche.

---

<div class="post-metadata">

**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\
**Post date:** [Juin 7, 2025, 3:06 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/10 "2025-06-07T15:06:42Z")

</div>

> [@Zargos](#):
>
> Aucun filtrage sur les hosts (IP) et DNS names?

Je ne vois pas où, mais il doit y avoir qqc qq part …  
Mon client 1 (pc avec firefox ou chromium) est, via un vpn, sur la même box que mon serveur  
Mon client2 (téléphone) n’est pas sur la box (pas en wifi)

> [@Zargos](#):
>
> C’est étonnant que n’ai rien dans les logs.

Oui  
Je vois bien les accès du site qui fonctionne en local (via mon /etc/hosts)  
Mais rien pour l’url qui passe par le dns de mon fai.  
Rien dans les logs, donc pb côté client probablement (possible avec vpn sur la même box) … mais pb aussi avec mon smatphone donc pb côté serveur …!

> [@Zargos](#):
>
> Essaye de voir en faisant 2 virtual hosts, sans alias.

Déjà fait, yc redémarrage de la box et cela ne change rien ! ☹

---

<div class="post-metadata">

**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\
**Post date:** [Juin 7, 2025, 3:54 UTC](https://www.debian-fr.org/t/site-https-inaccessible/91236/11 "2025-06-07T15:54:31Z")

</div>

Je viens de rebooter mon serveur … et ça fonctionne correctement 🙂

Sais pas pourquoi je n’y ai pas pensé avant et qu’est ce qui a pu occasionner ce comportement …
