search

AlternC / alternc-acme

GNU Affero General Public License v3.0
3 stars 8 forks source link

permettre identifier les fichiers et le nom de domaine #19

Open ddeenniiss opened 6 years ago

ddeenniiss commented 6 years ago

Je trouverais 1000 fois plus clair d'avoir une structure de dossiers qui reprenne les noms de domaines (comme le fait letsencrypt).

Par exemple, /var/lib/alternc/ssl/domain.tld/

Sinon, dans le vhost_all, on se retrouve avec 

  SSLCertificateFile /var/lib/alternc/ssl/private/0/90.pem
  SSLCertificateKeyFile /var/lib/alternc/ssl/private/0/90.key

Un truc du genre serait beaucoup plus simple et lisible:

  SSLCertificateFile /var/lib/alternc/ssl/private/domain.tld/90.pem
  SSLCertificateKeyFile /var/lib/alternc/ssl/private/domain.tld/90.key
camlafit commented 6 years ago

Bonjour

Pour information cela n'est pas spécifique au plugin certbot. C'est le fonctionnement natif d'AlterncC concernant les certificats.

Pour tout certificate-provider (dont celui ci) AlternC stocke en base les différentes informations relatives à chaque certificat. Ensuite quand le mode https est activé pour un domaine, les informations sont exportées et deposées dans /var/lib/alternc/ssl/ À noter on a a une exception avec celui du panel on utilise /etc/ssl/

Un certificat n'est pas spécifique à une domaine en particulier, on a d'autres cas comme les wildcard et les mutlidomaines (altnames). On peut aussi avoir plusieurs certificats pour un même domaine (un certificat let's encrypt et un certificat comodo). C'est pourquoi on ne peut avoir le chemin proposé, cela impliquerait d'avoir des liens symbolique ou de copier plusieurs fois le même certificat. Pour éviter ces problèmes on a fait le choix de nommer le certificat selon son identifiant. Chaque vhost faisant appel ensuite au meilleur certificat disponible.

En espérant avoir éclairci le comportement, en attendant d'avoir une vraie documentation :)

camlafit commented 6 years ago

Suite à une remarque sur IRC, j'ai oublié de préciser un point. Comme par défaut on considère qu'on a toujours un certificat actif, même pour les domaines déclaré en http, on prévoit la redirection https -> http. Ainsi pour tout domaine on a un certificat. Si on n'utilise aucun provider c'est un certificat autosigné, sinon le certificat du panel, sinon le certificat importé à la main, sinon le certificat d'un provider (certbot)

Pour rappel même un domaine http répond en https, c'est au pire le certificat panel. Donc avoir un certificat spécifique par domaine ne change rien à la situation de base. L'avantage c'est que maintenant si le certificat est valide alors il y a une redirection transparente vers http

ddeenniiss commented 6 years ago

Du coup, p-e au minimun un fichier de log avec ce qui a été fait et ce qui a été en erreur.

camlafit commented 6 years ago

Peux tu développer ? Que contiendrait ce fichier de log ?

ddeenniiss commented 6 years ago

Un truc du genre ?

Listes des domaines traités

domaine.tld -> certificat Let's encrypt OK /etc/letsencrypt/live/domain.tld -> copiés dans /var/lib/alternc/ssl/private/X/XXX ... domaine2.tld -> certificat NON ERREURX /etc/letsencrypt/live/domain.tld -> non copiés dans /var/lib/alternc/ssl/ ...

ddeenniiss commented 6 years ago

Pour les logs dans bureau.log aussi, ça semble incohérent.

Le cron de minuit, me met pour 60 domaines différents.

01/07/2018 00:20:00 - - CALL - wvw - certbot - import - new cert xxx OK

J'ai 13 nouveaux fichiers de certificats dans /var/lib/alternc/ssl/private/0/

Ce serait plus simple pour comprendre d'avoir dans bureau.log

01/07/2018 00:20:00 - - CALL - wvw - certbot - import - new cert xxx OK - /var/lib/alternc/ssl/private/X/XXX