Bonjour,
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 :www.nicolasgf.be
J’ai exécuté cette commande :cerbot delete puis apt install cerbo
Elle a produit cette sortie :
Mon serveur Web est (inclure la version) :
Le système d’exploitation sur lequel mon serveur Web s’exécute est (version incluse) :Debian 8 + apache2
Mon hébergeur, le cas échéant, est : local
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
Je rentre après 8 mois d'hopital(covid-19). Les certificats pour
igalerie.perso.nicolasgf.be
nextcloud.perso.nicolasgf.be
perso.nicolasgf.be. ont expirés.
pourriez-vous m'aider pour réactiver les certificats
j'ai supprimé cerbot et ensuite réinstallé apt install cerbot.
et rien ne fonctionne !
Merci d'avance
oui j'ai vider /etc/letsencrypt,
suite a la lecture de ce message "Il n'est pas possible de renouveler un certificat après son expiration, vous devrez créer un nouveau certificat"
Problem currently most likely is, is that your webserver is still expecting the certificate to be present in /etc/letsencrypt/. So you can't use the apache or nginx authenticator. However, you can use the webroot authenticator to issue a new certificate.
merci pour la bonne suite que vous réservez à ma demande
Peut-on se fier au lien suivant: https://rocketmap.readthedocs.io/en/develop/extras/letsencrypt.html
Certbot can automatically detect your webserver’s webroot, and complete the verification automatically, in addition to updating your webserver configuration itself.
For Apache users:
sudo certbot --authenticator webroot --installer apache
Certbot will ask you which domain name you wish to activate HTTPS for. Select the appropriate domain, and allow the verification to complete.
If you see the following message:
Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/example.com/fullchain.pem.
(actuellement /etc/letsencrypt)
Congratulations! Your SSL certificate was successfully generated and installed.
If you want to update your webserver configuration manually, you should manually specify your webroot and domain, such as:
sudo certbot certonly --webroot -w /var/www/example.com/ -d example.com
sudo certbot certonly --webroot -w /var/www/html/ perso.nicolasgf.be -d nextcloud.perso.nicolasgf.be -d igalerie.perso.nicolasgf.be
les résultats:
root@debian10club:~# certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
The requested apache plugin does not appear to be installed
aussi problèmes avec apache:
root@debian10club:~# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
No certs found.
root@debian10club:~# apachectl configtest
apache2: Syntax error on line 225 of /etc/apache2/apache2.conf: Syntax error on line 15 of /etc/apache2/sites-enabled/igalerie2-le-ssl.conf: Could not open configuration file /etc/letsencrypt/options-ssl-apache.conf: No such file or directory
Action 'configtest' failed.
The Apache error log may have more information.
You should install the apache plugin (I think it's called certbot-apache) using apt.
Also, due to the fact you've deleted the entire /etc/letsencrypt/ directory, your entire Apache configuration is now broken. So you need to use the webroot authenticator plugin (--webroot) combined with the certonly subcommand. See the Certbot documentation at User Guide — Certbot 1.22.0 documentation for more information.
Bonjour, veillez m'excuser pour ma lenteur.
le problème apache est résolu:
root@debian10club:~# apachectl configtest
Syntax OK
pouvez-vous m'expliquer comment retrouver l'accès non sècurisé http au site nextcloud
bien a vous
**j’ai recréé les certificats avec cerbot mais le lien « nextcloud.perso.nicolasgf.be » ne fonctionne pas ?** #certbot --apache -d perso.nicolasgf.be -d nextcloud.perso.nicolasgf.beYour existing certificate has been successfully renewed, and the new
certificate has been installed.
The new certificate covers the following domains: https://perso.nicolasgf.be and https://nextcloud.perso.nicolasgf.be
You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=perso.nicolasgf.be root@debian10club:~# nmap localhost | grep 443 443/tcp open https
root@debian10club:~# apachectl -t -D DUMP_VHOSTS
`VirtualHost configuration:
*:443 nextcloud.perso.nicolasgf.be (/etc/apache2/sites-enabled/nextcloud-le-ssl.conf:2) *:80 is a NameVirtualHost
default server nextcloud.perso.nicolasgf.be (/etc/apache2/sites-enabled/nextcloud-le-ssl.conf:20)
Well, your Nextcloud doesn't seem to work whether I'm using HTTP or HTTPS.. Looks like it's VERY slow, it takes many tenths of seconds to load even a simple redirect.
I'm not sure if that is related to the Let's Encrypt certificate though, as it seems to be occurring on HTTP as well as HTTPS.
Bonjour, les 2 liens suivants foctionnent sauf chez moi ! (problème de loopback) perso.nicolasgf.be ⇒ site en non sécurisé port 80 nextcloud.perso.nicolasgf.be => Sécurisé port 443 par défaut
Autre problème, la connexion au site est très lente, idem pour voyager dans le site.
Qu'en pensez-vous ?
I think you can overcome them with the power of DNS or other methods.
Locally:
within each system that is having this problem:
You can add entries in the hosts file for those names directing it to the internal IP.
within a local DNS system:
If your private network uses a private DNS server (that you control), you can add entries there to resolve those names to their internal IPs.
within the router:
If the NAT/router supports Hairpinning, then you could reach the internal IP via the external IP.
[but I suppose your router/NAT device doesn't support this or you would not be complaining]
Remotely:
using an Internet Proxy service to see your internal system from the Internet
use an Internet VPN service to tunnel all your HTTP(S) requests through an external IP