Asustor [resolu] Let's encrypt + vhost // Configuration du NAS

C

chryslertvert

Chevalier Jedi
21 Juillet 2014
206
0
16
Bonjour,

J'ai contacté le support car l'installation de vhost sur le NAS avec certificat SSL Let's encrypt (super nouveauté au passage) me causait des cheveux blancs.
Il y avait ce post: https://www.forum-nas.fr/viewtopic.php?f=11&t=4769&p=31668&hilit=vhost#p31668 mais je voulais en avoir le coeur net.
Ils ont toujours répondu avec rapidité et gentillesse, comme à leur habitude. Voici une synthèse avec quelques élément qui pourraient être utile à d'autres.

Avant propos
J'ai bien vu ce tuto sur let's encrypt: https://www.forum-nas.fr/viewtopic.php?f=54&t=4920
J'ai déjà installé et configuré un serveur fonctionnel (nginx pour le coup) avec let's encrypt. Mais je voulais le faire proprement en utilisant les outil d'ADM.

Synthèse de la situation
J'ai deux vhosts:
- le permier pour owncloud: owncloud.mondomaine.com
- le second pour un site statique: sub.mondomaine.com

J'ai deux certificats généré:
- celui par defaut d'asustor
- un pour le domain owncloud.mondomaine.com avec let's encrypt

Et deux problèmes:
1 - la redirection automatique http vers https
2 - la génération de nouveaux certificats let's encrypt

Sur les conseils du support, j'ai coché dans ADM / Configuration générale "redirection automatiques des connexions http vers https".

Ensuite, ils m'ont suggéré de coché par défaut mon certificat let's encrypt. Effectivement dans ce cas là https://owncloud.mondomaine.com fonctionnait parfaitement avec un certificat valide. Par contre, pas de redirection d'une part et cela me semblait bizarre que ce soit ce certificat qui soit utilisé également pour ADM et les autres applications. Conclusion, à mon sens, la solution n'était pas propre.

Le support m'a précisé :
Please note the NAS can only allow one certificate as default, and only the default certificate could be seen as trusted connection.
Cliquez pour agrandir...
> donc à priori, suivant le certificat coché par defaut, le deuxième certificat et les autres seraient caduques.

Comme cela me semblait bizarre ("in other words, i can't enabled 2 certificats: one by vhost apart the certificate by defaut used for ADM"), ils m'ont suggéré:
For the issue mentioned, you need to input the domain names in the subject alternative name to apply the one certificate to virtual hosts.
Cliquez pour agrandir...
> cela supposerait en d'autres termes, qu'à chaque fois que j'ajoute un vhost, sur le même domaine ou non, je suis obligé de modifier le certificat par défaut en ajoutant des domaines alternatifs.

Enfin, j'ai une erreur d'email lorsque j'essai de générer un second certificat let's encrypt:
Also, we do find the "Mail is not correct (Ref. 5016)" issue in current ADM version, the issue was reported to our engineer team and they are doing their best to fix it. I'll keep this ticket open and update the latest news about this in my reply.
Cliquez pour agrandir...
> donc l'erreur devrait être levée. Maintenant que j'y pense, mailserver est installé sur le NAS. C'est peut-être lui qui pose problème.

Conclusion
Comme l'avait suggéré Yakatape dans le post précédent (cf plus haut), l'interface graphique ne semble pas aujourd'hui apporté la souplesse suffisante pour une mise en place de multiple vhost bien certifiés, proprement. Du coup, vu que j'ai déjà un certificat let's encrypt fonctionnel, je vais essayer de suivre les conseils de Yakatape en modifiant à la main un premier vhost pour owncloud.

[edit] Au passage, sauriez-vous où sont stockés les certificats générés par let's encrypt (cert.pem, privkey.pem, fullchain.pem)? J'ai été voir du côté de /volume0/usr/builtin/etc/certificate/letsencrypt, et c'est vide alors qu'il m'est bien indiqué dans ADM qu'un certificat a été généré???

Je vous tiens au courant.

Bonne journée,
jb
 
/usr/builtin/etc/certificate/

car il me semble si je dis pas de bêtise que lighttpd / apache / nginx utilise des liens symbolic par défaut qui pointe vers le path ci-dessus.

Et en effet pour chaque domaine que tu va vouloir créer sur le plus ou moins long terme il te faudra à chaque fois recréer un certificat letsencrypt pour lui faire correspondre ton Alternative domaine.

c'est pour cela que pour ma part j'ai fini par laissé le certificat asustor par défaut tout en modifiant les lien symbolic en les faisant pointé sur mon certificat wildcard.

Ainsi je ne suis plus embêté, car j'avais fini par atteindre la limite de certificat lets encrypt à force d'en régénérer à chaque fois pour mes alternative domaine name.
 
Quand ton certificat let's encrypt est généré il réécrit il me semble directement dans les fichiers par défaut d'asustor d'où le fait que tu ne puisse en utiliser qu'un seul par défaut via l'interface ADM.

Look there via " ls -al /usr/etc/lighttpd/ ":
Code: 
lighttpd.chain -> /usr/builtin/etc/certificate/ssl.chain
 lighttpd.conf
lighttpd.pem -> /usr/builtin/etc/certificate/ssl.pem

Si tu a d'autres soucis ou besoin d'aide n'hésite pas je peux te filer un coup de main, ça sera avec plaisir
 
Grand merci Yakatape pour tout ces conseils.
Je pense pouvoir me repencher dessus ce week-end.
Ce qui me gène avec le certificat Asustor est qu'il est auto-signé. Du coup, les navigateurs demande de valider une exception pour entrer.

Par ailleurs, j'avais un problème avec la génération de certificat let's encrypt:
Code: 
Mail is not correct (Ref. 5016)
Le support m'a confirmé qu'il s'agissait d'un bug et qu'il devrait être réglé dans la prochaine version d'ADM:
For the issue mentioned, the let's encrypt issue was caused by the current ADM upgrade.
The ADM version which fix the issue is under verification now and will be released as soon as its verified.
Cliquez pour agrandir...

A suivre.

Bonne journée,
jb
 
Hello,

Je n'ai pas eu le temps de regarder de plus prêt.
Mais je pense que tu peux bypass l'interface adm pour utiliser letsencrypt. (je te ferais un retour sur le sujet ;) d'ici ce week end)
 
Bonjour,

Avec la mise-à-jour d'ADM (2.6.4.R9C2), le bug de génération de certificat let's encrypt a été résolu. Top!

Suite à nos échanges, Yakatape, j'ai retrouvé les certificats let's encrypt générés. Ils sont ici:
Code: 
/volume0/usr/builtin/etc/certificate/ssl/_xxx_/
Où _xxx_ sont des id identifié dans le fichier suivant:
Code: 
/volume0/usr/builtin/etc/certificate/certificate.json

Par contre, il y a un grand nombre de fichiers générés lors de l'émission du certificat:
Code: 
-rw-r--r--    1 root     root          3243 Sep 13 21:45 account.pem
-rw-r--r--    1 root     root          1663 Sep 13 21:45 cert.csr
-rw-r--r--    1 root     root          1647 Sep 13 21:45 chain.pem
-rw-r--r--    1 root     root         10879 Sep 13 21:45 openssl.cnf
-rw-r--r--    1 root     root          3802 Sep 13 21:45 ssl.chain
-rw-r--r--    1 root     root          2155 Sep 13 21:45 ssl.crt
-rw-r--r--    1 root     root          3243 Sep 13 21:45 ssl.key
-rw-r--r--    1 root     root          5398 Sep 13 21:45 ssl.pem

Du coup, j'ai essayé de configurer un de mes vhost ainsi:
Code: 
<IfModule mod_ssl.c>
<VirtualHost *:80>
    ServerName cloud.domaine.com
    Redirect permanent / https://cloud.domaine.com/
</VirtualHost>
<VirtualHost *:443>
    ServerName cv.soapoperator.com
    DocumentRoot "/volume1/Web/nextcloud"
    ScriptAlias /cgi-bin/ "/volume1/Web/cloud.domaine.com/cgi-bin"
    SSLEngine On
    SSLCertificateFile    "/volume0/usr/builtin/etc/certificate/ssl/_xxx_/ssl.crt" 
    SSLCertificateKeyFile "/volume0/usr/builtin/etc/certificate/ssl/_xxx_/ssl.key"    
    SSLCertificateChainFile "/volume0/usr/builtin/etc/certificate/ssl/_xxx_/ssl.pem"      
    <Directory "/volume1/Web/cloud.domaine.com">
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order Allow,Deny
        Allow from all
    </Directory>
</VirtualHost>
</IfModule>

Mais à priori, ce ne sont pas les bons fichiers que j'ai utilisé, car cela ne change rien dans le navigateur.

A suivre donc.

Bonne journée,
jb
 
Bonsoir,

En fait, j'ai noté que mes vhost étaient remis à zéro lorsque je redémarre le web server (méthode ADM: disable > web server > apply > enable > apply)... Conclusion mes modifications ne sont pas sauvegardées.

Pour les certificats, j'ai utilisé la méthode suggérer par le support Asustor (mais qui ne me semble pas "propre"): ajouter tous mes domains en alias de mon domaine principal. Ca marche.

Reste donc la redirection http > https.

Bonne soirée,
jb
 
chryslertvert a dit:
Bonsoir,

En fait, j'ai noté que mes vhost étaient remis à zéro lorsque je redémarre le web server (méthode ADM: disable > web server > apply > enable > apply)... Conclusion mes modifications ne sont pas sauvegardées.
Cliquez pour agrandir...

Hello jb,

Tu as exactement mis le doigt là où il fallait :rolleyes: :p En effet étant donné que nous faisons un bypass de l'interface ADM afin d'affiner la configuration apache, lorsque celui-ci (le service Web) est redémarré via l'interface Web asustor les fichiers de conf sont remis à zéro (ou du moins avec la configuration minimale géré par l'interface).

C'est pour ça que je me suis fait un script qui me sauvegarde mes fichiers http & https custom dans un répertoire spécifique qui de ce fait n'est pas écrasées ni par les MAJ ADM ni par un restart du NAS ou du service WEB.

Ainsi si les fichiers de conf apache sont remis à zero j'ai juste à faire un :
pour HTTP : "cat /my/repository/backup/http.conf > /usr/builtin/etc/apache2/sites-enabled/@default"
pour HTTPS : "cat /my/repository/backup/https.conf > /usr/builtin/etc/apache2/sites-enabled/@default-ssl"

PS : toutes mes excuses pour mon retour tardif ! un peu déborder en ce moment :)

Excellente soirée,
Seb,
 
Hello Yakatape,

Merci pour votre réponse. Et ne m'inquiétait de ne pas avoir de nouvelles.
J'ai résolu le problème à l'aide de vos tutos:
https://getbrain.fr/gestion-vhost-nas-asustor/
https://getbrain.fr/nextcloud-sur-asustor/

Par contre, je ne n'ai pas mis en place votre scipt. Enfin pas encore.
Concernant les commande que vous utilisez, une petit question technique pourquoi
Code: 
cat
et non
Code: 
cp -p

Concernant la gestion des vhost, j'espère que ADM 3 amènera quelques menues améliorations. Et pourquoi pas se passer de apache au profit de nginx :geek:

Bon je passe le post en resolu.

Bonne journée,
jb
 
Hello jb,

Alors cat permet d'afficher le contenu du fichier sans le besoin de le copier ou de le déplacer, avec le ">" on redirige l'output du cat.
">" on ecrase le contenu existant du fichier pointé.
">>" on incrémente le contenu du fichier pointé.

Alors que le cp lui va créer un fichier de plus dans le repertoire ce dont nous n'avons pas besoin.
Et pour conserver les droits, heure de creation/modification d'un fichier etc.. je préfére l'utilisation de rsync (pour ma part).

Pour ce qui est de l'eternel duel entre apache et nginx ..
Apache est plus puissant pour du contenu dynamic et de pars ses nombreux modules alors que nginx lui est plus orienté pour du contenu static..
Par exemple pour du php il me semble que nginx doit passer par un process externe pour traiter la requete, ensuite récupérer le contenu et la renvoyer alors que les instances apache le fond dynamiquement via ses workers. Chacun répond à un besoin spécifique que se soit en terme de performances, d'administration au niveau systeme etc.. :rolleyes:
 
Vous devez vous connecter ou vous enregistrer pour répondre ici.
Haut Bas
Retour