Bizarre pourquoi toi y a tu acces et pas moi …
Ce que je comprends pas c’est j’ai mit le nom du site sur une liste https://hstspreload.org/removal/?domain=aracall.ovh donc le site ce trouvant toujours sur cette liste ça explique pourquoi hsts est encore là …
mais ça explique pas pourquoi toi t’a accés au site sans ssl en plus … donnc sans hsts …
Oui, j’ai eu le même message de sécurité, ce qui signifie que c’est un certificat auto-signé. Je n’ai jamais copié de certificat de serveur à un autre. Pour certbot il faut juste attendre quelques minutes histoire que les DNS ce mettent à jour, après tu pourras refaire un nouveau certificat.
Sur ton site j’étais bien en https et non http.
Est-il possible d’avoir le contenue de 000-default.conf ?
Sinon aucun rapport avec le problème, mais c’est normal qu’il n’y a pas possibilité de ce log sur ton site ?
EDIT :
Pour enlevé hsts il te suffit de commenter cette ligne:
Strict-Transport-Security “max-age=31536000; includeSubDomains; preload” env=HTTPS
@didi44 Je viens de regarder de nouveau et j’ai bien fait, dans la zone dns l’enregistrement A ne pointé pas vers le vps … je suis pourtant sûr de l’avoir fait hier … pour une raison inconnu il semble que les changements n’aient pas étaient prit en compte …
Du coup je suppose que en allant sur le site comme tu l’as fait la redirection était celle du serveur d’hébergement et non celui du vps.
Avant d’acheter le vps c’est effectivement quelque chose que j’avais remarqué mais ça ne ce produisait que sous chrome et chromium ras pour firefox.
Je suppose que ça fait parties des nombreuses erreurs impossible à corriger sans un terminal.
Au cas où voici le contenu de 000-default.conf provenant je précise du vps donc de la nouvelle configuration et je pense qu’il ne t’interessera pas car il est vierge.
<VirtualHost *:80>
The ServerName directive sets the request scheme, hostname and port that
the server uses to identify itself. This is used when creating
redirection URLs. In the context of virtual hosts, the ServerName
specifies what hostname must appear in the request’s Host: header to
match this virtual host. For the default virtual host (this file) this
value is not decisive as it is used as a last resort host regardless.
However, you must set it for any further virtual host explicitly.
ServerName www.example.comServerAdmin webmaster@localhost
DocumentRoot /var/www/htmlAvailable loglevels: trace8, …, trace1, debug, info, notice, warn,
error, crit, alert, emerg.
It is also possible to configure the loglevel for particular
modules, e.g.
LogLevel info ssl:warnErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combinedFor most configuration files from conf-available/, which are
enabled or disabled at a global level, it is possible to
include a line for only one particular virtual host. For example the
following line enables the CGI configuration for this host only
after it has been globally disabled with “a2disconf”.
Include conf-available/serve-cgi-bin.conf
vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Celui ci au contraire et le fichier de conf du site
<VirtualHost *:80>
ServerAdmin admin@example.com
DocumentRoot /srv/nextcloud/
ServerName aracall.ovh
ServerAlias www.aracall.ovh
ErrorLog /var/log/apache2/nextcloud-error.log
CustomLog /var/log/apache2/nextcloud-access.log combined<Directory /srv/nextcloud/>Options +FollowSymlinks
AllowOverride All
Require all granted
SetEnv HOME /srv/nextcloud
SetEnv HTTP_HOME /srv/nextcloud
Dav off
EDIT : confirmation faite sous firefox possibiliter de ce log
D’accord c’est surement pour cela que je n’y ai plus acces.
Cette ligne est-elle commenté : Strict-Transport-Security “max-age=31536000; includeSubDomains; preload” env=HTTPS ?
Actuellement cette ligne je ne l’ai ajouté que dans le fichier de configuration situé sur l’hébergeur “à l’époque” où le certificat était ok
elle n’ai pas encore presente sur le vps puisque certbot me refuse la gérèration d’un nouveau certificat c’est peut être un peu flou dit comme ça non ? entres les fichiers de conf ancien de l’hébergeur et ceux du nouveau si c’est flou je vais tenté de réexpliquer j’explicite peut être pas de façon suffissament clair on a peut être vite fait de s’embrouiller x)
Oui je m’y perd un peux 
Nous allons reprendre histoire de bien comprendre la situation.
Tu fait une install complète de nextcloud sur le nouveau serveur ? J’imagine que oui.
Comment as tu mis en place l’https sur ton nouveau serveur ?
Et autre question quelle est le répertoire de ce fichier :
<VirtualHost *:80>
ServerAdmin admin@example.com
DocumentRoot /srv/nextcloud/
ServerName aracall.ovh
ServerAlias www.aracall.ovh
ErrorLog /var/log/apache2/nextcloud-error.log
CustomLog /var/log/apache2/nextcloud-access.log combined
<Directory /srv/nextcloud/>
Options +FollowSymlinks
AllowOverride All
Require all granted
SetEnv HOME /srv/nextcloud
SetEnv HTTP_HOME /srv/nextcloud
Dav off
Et aussi pourquoi certbot n’arrive pas à faire de nouveau certificat.
Merci.
Il vaut mieux donner trop de détails que pas assez je pense que ça aidera à la compréhention.
_ Le tout premier site pour lequel je suis venu au début de ce post, il était hebergé par ovh, c’était pour être plus précis un hébergement mutualisé.
Conséquence de cette mutualisation, impossible d’avoir de terminal et d’enlever certains problèmes rencontré au début de ce post.
Néanmoins, toujours sur cet hébergement, je possédais un certificat let’s encrypt offert par ovh et installé automatiquement par eux. (que j’ai désactiver depuis pour que certbot ne rentre pas en conflit avec “le certificat d’ovh” ) Et j’ai de moi même ajouté le hsts.
Suite à ce posts ci, et comme @didi44 me l’as souligné, impossible de régler certains problemes sans avoir de terminal.
Donc, j’ai décidé d’acheter un vps, et j’ai recrée un site entier !
J’ai donc effectué le redirection du nom de domaine sur l’ip du vps. Malheureusement, étant donné que j’avais avant ça comme décris plus haut activé le hsts, impossible d’accéder au site (en tout cas sur firefox pc )
Sur le nouveau serveur justement j’ai voulu installer le certificat à l’aide de certbot, mais certbot me parle à priori d’un probléme relatif à la zone dns qui est mal configuré.
Donc pour avoir regardé entre temps, effectivement pour une raison inconnu quand hier j’ai pointé le nom de mon domaine sur le vps, il semblerait que ça ne l’ai pas enregistré chez ovh ( je me souvient bien pourtant avoir eu confirmation du changement, mais bon passons )
Concrétement j’attends donc que le temps de propagation de ma zone dns soit terminé et que la redirection soit effective, d’aprés ovh ça peut prendre jusqu’à 24h (sous réserve d’avoir compris correctement ) Éditer une zone DNS OVHcloud - OVHcloud
Je les cite :
Une fois la zone DNS OVH de votre nom de domaine modifiée, un temps de propagation de 24 heures maximum est nécessaire afin que les modifications soient effectives.
Donc normalement, si tout va bien certbot validera mon certificat une fois que la propagation sera terminé. Par contre, en attendant que la propagation soit effective, je suppose que le site auquel on accéde pointe toujours sur le serveur qui posséde l’hébergement mutualisé ( l’ancien site ) et ceux tant que la propagation ne sera pas totalement effective.
Le repertoire de ce fichier est le suivant :
/etc/apache2/conf-enabled/nextcloud.conf
Et ce fichier ce situe donc, sur le vps, là où la nouvelle installation ce situe
Merci beaucoup pour toute les précisions !
C’est maintenant plus claire.
Ok pour certbot nous verrons cela demain.
Pour ton nextcloud.conf.
Il n’a rien à faire dans conf-enabled !
Il faut le mettre dans site-available c’est là que ce trouve les confs des site-web.
puis faire un a2ensite nextcloud.conf et sudo systemctl restart apache2
Pour l’https je veux bien que tu active la conf par défaut.
Tu pourras t’y connecter sans certificat en rentrant l’ip directement dans ton naviguateur.
Hum, pour activer même la conf par défaut ça ce situe dans site-available defaut-ssl.conf je suppose ?
J’ai me tromper quelque part, j’ai transféré nexcloud.conf dans site-available et il me dit ça quand je lance a2ensite, le fichier s’y trouve belle est bien pourtant
ERROR: Site /etc/apache2/sites-available/nextcloud does not exist!
Oui c’est ça. Il te suffit de faire un a2ensite default-ssl.conf.
Tu as bien fait a2ensite nextcloud.conf et non pas nextcloud ?
Il me dit ceci
Site default-ssl already enabled
Justement, en fait voyant que ça ne fonctionnait pas je me suis dit que peut être que .conf le gêner avant de me souvenir que les extensions n’ont normalement aucuns effet. Donc oui il me dit quand même ça dans les deux cas.
Bien nous verrons après.
C’est peut-être parce que c’était un lien symbolique. Dans ce cas copie le contenue du fichier. Supprime le dans “site-available” puis créer de nouveau le fichier avec touch /etc/apache2/site-available/nextcloud.conf puis met ce que tu as copié dans le fichier et enfin a2ensite nextcloud.conf pour l’activer.
ok, j’ai fait ce que t’a dit effacer et recréer le fichier
To activate the new configuration, you need to run systemctl reload apache2
root@vps-5972c404:/etc/apache2/sites-available# systemctl reload apache2
root@vps-5972c404:/etc/apache2/sites-available# sudo a2ensite nextcloud.conf
Site nextcloud already enabled
Bien,
Nous allons pouvoir continuer.
Ton site est maintenant accessible en http mais pas en https. C’est déjà un bon point. Et j’ai même les inputs pour me log !!!
Nous allons voir ensemble l’https. Est-il possible d’avoir le fichier default-ssl.conf s’il te plaît ?
Nous avons bientôt terminé Ton serveur sera bientôt impécable.
ServerAdmin aracall.ovhDocumentRoot /srv/nextcloud # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, # error, crit, alert, emerg. # It is also possible to configure the loglevel for particular # modules, e.g. #LogLevel info ssl:warn ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined # For most configuration files from conf-available/, which are # enabled or disabled at a global level, it is possible to # include a line for only one particular virtual host. For example the # following line enables the CGI configuration for this host only # after it has been globally disabled with "a2disconf". #Include conf-available/serve-cgi-bin.conf # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # A self-signed (snakeoil) certificate can be created by installing # the ssl-cert package. See # /usr/share/doc/apache2/README.Debian.gz for more info. # If both key and certificate are stored in the same file, only the # SSLCertificateFile directive is needed. SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCACertificatePath /etc/ssl/certs/ #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath /etc/apache2/ssl.crl/ #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. # BrowserMatch "MSIE [2-6]" \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0
Hum … J’aimerais bien pouvoir comprendre je pensais que le message provenait de la liste de diffution hsts apparemment non …
Je pensais comprendre en fait je comprends moins que ce que je pensais 
peux tu m’éclairer sur ce qu’il s’est passé ?
Merci pour ta patience et ton aide en tout cas !!! 
EDIT : certbot à l’air d’avoir fonctionné … en tout cas c’est ce qu’il me dit … par contre pas de https en vu quand j’actualise le site
Bien, j’ai fais deux trois modifs sur le fichier, le voici :
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin aracall.ovh
ServerName
DocumentRoot /srv/nextcloud
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
</IfModule>
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
# BrowserMatch "MSIE [2-6]" \
# nokeepalive ssl-unclean-shutdown \
# downgrade-1.0 force-response-1.0
</VirtualHost>
</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Juste pour ServerAdmin il faut mettre ton email et dans ServerName ce que tu as mis dans ServerAdmin. Je n’ai pas modifié, je te laisse le faire.
Source : core - Serveur HTTP Apache Version 2.4
Je ne comprend pas vraiment ce que tu comprend pas.
Mais je pense avoir un peux compris.
Je deviens bon en rime.
Bref, le HSTS permet de forcer le connection en https au serveur. Ce qui veut dire que si j’éssaye de me connecter à ton serveur sans l’en-tête https, le serveur le fera de manière automatique. Cela apporte beaucoup en sécurité, il empèche les attaques du type man-in-the-middle.
Mais sur ton serveur j’ai pu m’y connecter en http car aucune redirection en https a été configuré. En effet il faut plusieurs ligne pour configurer tout cela.
La première c’est Redirect permanent / https://ip/ qui se met dans une configuration apache qui écoute le port http (80), ainsi toutes les requetes sont renvoyé en https. Mais ce n’est pas suffisant le HSTS se configure avec la ligne suivante :
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15552000;includeSubDomains"
</IfModule>
Là tout passe en https. Après pour toi tu avais le problème du certificat qui était invalide mais je m’avance pas trop car je sais pas si c’est lui ou autre chose. Une chose est sûre c’est qu’en http simple le certificat ne serre à rien donc je peux me connecter.
Dis moi si je me suis planter dans la réponse à ta question.
Grossomodo je savais ce que t’a dit, mais c’est je pense un manque de pratique, je me suis aussi possiblement moi-même embrouiller dans les fichiers de conf à force d’être le nez dedans
mais oui du coup t’a répondu à ma question j’avais pas de redirection sur du https
du coup certbot a fonctionné et a généré une pair de clé privée correspondant au certificat.
Mais ce que je comprends pas c’est que j’ai toujours pas de https … pourtant je l’ai déjà fait y a pas longtemps sur une autre config et certbot avait tout configuré seul une fois lancé
Dans le fichier que t’a compléte il y a ces lignes ci
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
#SSLCACertificatePath /etc/ssl/certs/ #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
Si je lui indique les files généré par certbot à la place ça changera quelque chose ? ( je ne vois pas par quelle autorité ceux de base ont étaient généré en fait … ?