Mettre un certificat https sur un apache2

Support Debian
#1

salut
on me demande la chose suivante :

Attention toutefois a bien faire configurer le serveur web pour qu’il écoute sur le port tcp 443 (HTTPS) avec le certificat *.chu-machin.fr et non pas le tcp 80 (HTTP) comme c’est le cas actuellement.

mon site sera https://trach.chu-machin.fr
Je n’ai aucun accès à chu-machin.fr

Mais
Je n’ai aucun fichier .pem .crt .csr .key

J’ai essayé des trucs , par exemple

openssl genrsa -out trach.chu-machin.fr.key 1024
openssl req -new -key trach.chu-machin.fr.key -out trach.chu-machin.fr.csr

j’ai un .key, un .csr mais rien de concluant, en particulier on ne m’a pas demandé le nom du certificat.

Que dois-je faire pour associer mon site au « certificat » *.chu-machin.fr ?

C’est sur une debian 10 ( virtualisée sous un windows server ( snif ) qui adore me dire « vous n’avez pas le droit » ).

merci par avance

#2

Bonjour,

si tu n’as pas accès à la gestion de la zone DNS du domaine chu-machin.fr, tu vas devoir générer un certificat wildcard autosigné.
Tu peux en effet utiliser openssl pour ça.
Tu as généré une clé et un CSR, mais le CSR est une requête de certificat, c’est un fichier que tu transmets à ton autorité de certification lorsque tu lui demandes un nouveau certificat. Pas besoin ici puisque tu dois te passer d’autorité de certification.
Il te reste juste à générer le fichier certificat avec openssl:
openssl req -new -x509 -nodes -sha256 -days 365 -key taclé.key > ton.certificat

#3

salut
merci beaucoup
j’avais trouvé effectivement cette commande ( un peu différente, j’avais tapé ,

openssl req -new -x509 -nodes -sha1 -days 365 -key server.key -out server.crt -extensions usr_cert
  1. la tienne est-elle meilleure ? Le sha est mieux, mais je ne sais pas si je peux choisir où si je dois demandé.
  2. pour le FQDN ( je dois mettre trach.chu-machin.fr ou *.chu-machin.fr ?
  3. qu’est-ce que j’en fais?
    dans mon sites-available/default-ssl.conf
    j’ai
    SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
    #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

je mets le dièze sur la première (.pem que je n’ai pas ) et je l’enlève sur la deuxième ( .crt que je crée ) ?
J’ai l’impression de l’avoir déjà fait et que ça n’a pas marché.

  1. je ne le fais qu’avec les fichiers de conf de apache2? Pas besoin de le faire sur mysql, l’OS ?

Merci

PS : aides :


#4

Il n’y a aucun rapport avec le DNS.
par contre il est necessaire d’avoir un lien avec qui gère l’autorité de certification de chu-machin.fr
S’il n’existe pas c’est l’occasion d’en créer un.

Si c’st publique non, en interne il te faut en créer une autosignée le cas échéant.

Il faut générer le certificat racine qui servira ensuite à signer les autres.

#5

salut
je n’y arrive toujours pas
j’utilsie openssl pour créer blah.key que je mets dans /etc/ssl/private et blah.crt que je mets dans /etc/ssl/certs

dans mon /etc/apache2/sites-available/blah.conf je mets
SSLEngine on
SSLCertificateFile /etc/ssl/certs/blah.crt
SSLCertificateKeyFile /etc/ssl/private/blah.key

je n’ai pas de .pem
je n’ai pas mis de ou <Directory /usr/lib/cgi-bin> dedans

puis a2enssite, apache2 reload
mais je n’obtients que des erreurs 500 par https

#6

Bonjour,

Plutôt que dire ce que tu as mis et ce que tu n’as pas mis, donne-nous ton fichier d’hôte virtuel complet.

#7 
<VirtualHost *:443>
	ServerName blah.chu-grenoble.fr
	ServerAlias www.blah.chu-grenoble.fr

	DocumentRoot /var/www/html/blah
	LogLevel info ssl:debug
	LogLevel debug
	ErrorLog ${APACHE_LOG_DIR}/blah_error.log
	CustomLog ${APACHE_LOG_DIR}/blah_access.log combined

SSLEngine on

SSLCertificateFile /etc/ssl/certs/blah.crt
SSLCertificateKeyFile /etc/ssl/private/blah.key

<Directory /var/www/html/blah/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>

</VirtualHost>




 
<VirtualHost 100.100.100.100:443> 

	ServerName blah.chu-grenoble.fr
	ServerAlias www.blah.chu-grenoble.fr

	DocumentRoot /var/www/html/blah
	LogLevel info ssl:debug
	LogLevel debug
	ErrorLog ${APACHE_LOG_DIR}/blah_error.log
	CustomLog ${APACHE_LOG_DIR}/blah_access.log combined
SSLEngine on

SSLCertificateFile /etc/ssl/certs/blah.crt
SSLCertificateKeyFile /etc/ssl/private/blah.key

<Directory /var/www/html/blah/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>

</VirtualHost>

l’erreur:

The page cannot be displayed
Explanation: There is a problem with the page you are trying to reach and it cannot be displayed.

Try the following:

    Refresh page: Search for the page again by clicking the Refresh button. The timeout may have occurred due to Internet congestion.
    Check spelling: Check that you typed the Web page address correctly. The address may have been mistyped.
    Access from a link: If there is a link to the page you are looking for, try accessing the page from that link. 

Technical Information (for support personnel)

    Error Code: 500 Internal Server Error. The certificate chain was issued by an authority that is not trusted. (-2146893019)

création des fichiers

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/blah.key -out /etc/ssl/certs/blah.crt
#8

C’est un certificat auto-signé, c’est donc normal que le navigateur râle.

Par contre, pourquoi ton hôte virtuel est-il défini deux fois : une fois par nom est une fois par IP ?
Vérifie les droits d’accès sur les clés et la configuration d’apache :

sudo apache2ctl -t
#9

parce qu’un seul ne marchait pas alors j’ai tenté les deux
évidemment j’ai testé les deux blocs indépendamment.

syntax ok
vous avez du nouveau courrier …

apache2ctl -S

VirtualHost configuration:
100.100.100.100:443       blah.chu-grenoble.fr (/etc/apache2/sites-enabled/blah.conf:53)
*:443                  blah.chu-grenoble.fr (/etc/apache2/sites-enabled/blah.conf:4)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/apache2.conf.error.log"
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default 
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33
#10

Ce n’est pas ce qui ressort de tes derniers retours. Supprime toute la partie :

<VirtualHost 100.100.100.100:443> 
…
</VirtualHost>

et recharge la configuration d’Apache.

#11

salut,
ce que je voulais dire, c’est que j’ai tout d’abord essayé la configuration avec *443 , puis IP:443 puis les deux .
Bon la je viens de mettre juste avec *:443
dans sites-enabled je n’ai que un fichier conf, le mien , après a2dissite, apache2 reload et a2ensite

#12

Ton serveur doit avoir la chaine de certification au format pem

#13

C’est déjà le cas avec la commande openssl utilisée.

S’il y a toujours une erreur 500, il faut vérifier le certificat et les droits d’accès sur les fichiers.

#14

Ah… blah.crt est en fait le certificat racine.

Normalement tu créé un certificat racine auto-signé.

Puis une clef pour ton serveur toto.domain.tld dans les paramètres de création du certificat (sinon ça ne marche pas)

Puis un certificate request à partir de la clef

Puis tu signe le certificate request avec le certificat racine.

#15

On peut effectivement créer un certificat auto-signé en deux étapes : d’abord le CSR, puis le certificat. Mais je ne suis pas sûr que cela change quoi que ce soit.

openssl req -new -nodes -keyout blah.key -out blah.csr -newkey rsa:2048  -sha256

Puis signature :

openssl x509 -req -days 365 -in blahg.csr -blah.key -out blas.crt

Je pense plutôt que le problème de @dindoun vient d’un certificat invalide. On attend donc la vérification de celui-ci.

#16

merci de votre aide

j’avais essayé ça mais sans succès particulier;

je me demandais si la taille de la clé rsa (2048,1024) devait concorder avec celle du niveau au dessus.

Je n’ai pas de .pem mis à disposition.

J’ai vraiment été étonné de devoir autosigner.

Tu aurais des commandes à essayer? Même si elles sont approximatives ça m’intéresse.

#17

Personnellement pour gérer mes certificats j’utilise XCA sur une VM dédiée aux certificats et d’une façon générale tout ce qui relève d’une PKI. XCA marche plutôt bien.

J’ai un CA root puis 3 sub CA pour les différents domaines de certificats que j’utilise.
Seul les SUB-CA sont exposé, jamais le CA.

De fait si un sub CA est compromis, je le révoque, révoquant ainsi d’un seul coups tous les certificats qui en dépendent.