Erreur ANotWorking en résultat diagnostic Let's Debug

Help Aide (en français)
1

Veuillez remplir les champs ci-dessous pour que nous puissions vous aider. Remarque : vous devez fournir votre nom de domaine pour obtenir de l’aide. Les noms de domaine des certificats émis sont tous rendus publics dans les journaux de Transparence de Certificat (par exemple, crt.sh | example.com). Par conséquent, le fait de ne pas indiquer votre nom de domaine ici n’aide pas à le garder secret, mais rend plus difficile pour nous le fait de vous aider.

Je peux lire des réponses en Anglais : oui

Mon nom de domaine est : dev.cogetep.fr

J’ai exécuté cette commande : Let's Debug

Elle a produit cette sortie : ANotWorking - "GET http://dev.cogetep.fr/.well-known/acme-challenge/letsdebug-test ... :connect: connection refused"

Mon serveur Web est (inclure la version) : Apache/2.4.59 (Fedora linux)

Le système d’exploitation sur lequel mon serveur Web s’exécute est (version incluse) : Fedora Linux 39 (Workstation Edition) Noyau Linux 6.8.11-200.fc39.x86_64

Mon hébergeur, le cas échéant, est : serveur propriétaire

Je peux me connecter à un shell root sur ma machine (oui ou non, ou je ne sais pas) : oui

J’utilise un panneau de configuration pour gérer mon site (non, ou fournit le nom et la version du panneau de configuration) : non

Enregistreur du nom de domaine (DNS) : Gandi

Ci-dessous un extrait de la configuration du serveur hôte virtuel du domaine dev.cogetep.fr

14h1d messites.conf_20241002_3_retourarriere_modification
14h1d messites.conf_20241002_3_retourarriere_modification1020×592 67.8 KB

Le résultat du test Let's Debug n'évolue pas après avoir désactivé le pare-feu sur le serveur, ce qui devrait écarter l’hypothèse d’un problème de configuration du pare-feu

J'ai appliqué des recommandations lues sur la documentation « Support IP v6 » en ligne, mais sans résultat:

  • suppression de l'enregistrement AAAA dans le DNS
  • suppression de la redirection HTTP vers HTTPS côté serveur hôte virtuel

Pourriez-vous m'éclairer et me guider s'il vous plait ?

2

Is the configured IP address for your hostname, currently 81.220.55.207, correct? Because your site seems to be working using IPv6, but the IPv4 address does not respond at all. Not on port 80, not on port 443, nothing.

1 Like
3

I can't connect to you with either IPv4 or IPv6 (for http or https). And, Let's Debug says both are failing too. Maybe something changed since your first post but still not working

I also wanted to say that you have a ServerAlias for a www subdomain but do not have any DNS A and/or AAAA entries for that domain name. You will need that for anyone to use that name too.

nslookup dev.cogetep.fr
A   Address: 81.220.55.207
AAAA Address: 2a02:8429:d44b:ea01:d9cc:3f4:1d97:810d

nslookup www.dev.cogetep.fr
** server can't find www.dev.cogetep.fr: NXDOMAIN
3 Likes
4

Thanks Mike,
Thank you for your responsiveness.
Indeed I had turned off the server, it is back in service now. Thanks for reporting the Server Alias. I removed it just now to focus on access to the dev.cogetep.fr domain.

1 Like
5

Thanks OSIRIS,
I did not configure a fixed IP address and indeed the v4 IP address has changed in the meantime. I just updated it in the DNS and firewall side. The original problem persists.

1 Like
6

Are you sure the new IPv4 address is correct? Because I can ping the IPv6 address, but not the current IPv4 address (81.220.54.188).

Are there any NAT devices in play?

1 Like
7

The IPv6 address is working and Let's Encrypt prefers that.

You redirect the HTTP challenge to HTTPS. Can we see your VirtualHost for port 443? Because that is the one handling the challenge because of your redirect

Note the httpS in the URL reported by a Let's Debug test. And the IPv6 address

Challenge update failures for dev.cogetep.fr in order https://acme-staging-v02.api.letsencrypt.org/acme/order/5751349/19593402303

acme: error code 403 "urn:ietf:params:acme:error:unauthorized": 2a02:8429:d44b:ea01:d9cc:3f4:1d97:810d: Invalid response from https://dev.cogetep.fr/.well-known/acme-challenge/zlD9v3krK9AbhgUhWe0hsiecDM9gwscIcpd6caiyr7s: 404

3 Likes
8

The address 81.220.54.188 seems correct to me because I can ping it from my PC connected to the same local network as the host server.

9

Here is VirtualHost for port 443

messites.conf_20241006
messites.conf_202410061056×460 59.8 KB

10

But it doesn't work from the world wide web: all result in a "Connection timed out" error. See e.g. https://check-host.net/check-http?host=dev.cogetep.fr or similar websites. (Note that some use IPv6 which does work, but apparently this website uses IPv4 only..)

1 Like
11

Thank you OSIRIS.
Is it worth me temporarily disabling the firewall to see if the problem is there?

1 Like
12

Worth a try indeed.

1 Like
13

firewall disabled

14

Still no reply for 81.220.54.188 on port 80 nor 443.

Is the server behind a NAT router?

1 Like
15

not on the server to my knowledge. The equipment located upstream is the internet operator box (SFR).

16

Well, something is blocking access to port 80/443 (or any port for that matter) on IPv4..

Anyway, as Let's Encrypt prefers IPv6, maybe you need to sort IPv4 out later and first concentrate on getting a certificate with the tips from @MikeMcQ.

Also, I'm not sure if there actually is a Let's Encrypt issue currently. I think renewal should work, although your certificate is not ready for renewal just yet.

2 Likes
17

All right. To do without IP v4, do I just have to delete the A record in DNS, is this correct?

18

No, that's not necessary. Let's Encrypt prefers IPv6 and will use the IPv6 address by default.

2 Likes
19

Hello MikeMcQ,
I don't know how to accurately interpret the error message returned by the ACME challenge. I nevertheless noted a certain number of signals in the various server traces. Before I launch into an in-depth analysis of each one to try to correct them one by one, could you tell me which one seems to you to have the greatest potential for correcting my ACME challenge problem. Thank you :
1- The user (root) does not have the right to write in the root folder of the domain (defined by the DocumentRoot directive of the Virtual Host of the domain)
2- Presence of the error message “AH01909: localhost:443:0 server certificate does NOT include an ID which matches the server name” in the ssl_error_log file (http server)
3- In the system logs (file /var/log/messages) which trace in particular the errors linked to the SELinux policy, we see SELinux errors (message 'avc: denied') exclusively on the process related to the executable '/usr/bin/dbus-broker'
4- Access rights to the folder /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org: The owner is root, the type in the SELinux label is etc_t

20

What is that error? We debug problems in ACME Clients every day. Knowing the actual error helps focus debug efforts.

And, what is the ACME Client that you are using. Different ones have different options to help debug. Please also note its version

As for your specific items 1-4
1 - Seems odd that root would not have access to write to DocumentRoot
2 - not related
3,4 - I am not SELinux expert

But, without knowing the current error message it is hard to say what kinds of problems are most likely

3 Likes