Remplacement certificats

Le Sat, 18 Jan 2014 09:21:03 +1100,
Doug713705 <doug.letough@free.fr> écrivait :

Bonjour à toutes, tous,

Bonsoir,

Je loue une dedibox pour laquelle j'avais acheté un nom de domaine qui
aujourd'hui ne m'appartient plus.

J'ai maintenant en ma possession un autre nom de domaine et j'ai changé
le nom d'hôte de la machine pour refléter ce changement et tout roule
nickel. La machine a bien son nouveau nom pris en compte, bind9
fonctionne parfaitement, tout est propagé, impecc' o/ ).

Cependant il me reste à remplacer les certificats afin qu'ils
correspondent également à ce nouveau nom de domaine mais avant de faire
une bêtise et de me retrouver dans une impasse inextricable j'aimerai
être sûr de ne rien oublier mais également de faire les choses dans
le bon ordre.

Pour tout dire mes connaissances en la matière sont très maigres et le
but est de reconfigurer totalement le serveur (Debian Wheezy) pour qu'il
héberge (au moins) les services suivants :
- sshd (authentification par clefs RSA)
- openvpn (c'est là que le remplacement de certificat me fait un
peu peur)
- Nginx (avec support ssl)
- postfix / dovecot / rouncube (Sasl / mysql)
- Spamassassin / Clamav / Greylist
- Apache2 (mais je ne sais pas encore dans quelle mesure cela va entrer
en conflit avec Nginx, s'il faut s'en passer ce n'est pas un problème)

Pour l'installation de toute cette salade, je projette de suivre le
tutoriel suivant (mais sans passer par un dépôt alternatif comme
mentionné et dont je ne vois pas l'intérêt) :
http://www.xenlens.com/debian-wheezy-mail-server-postfix-dovecot-sasl-mysql-postfixadmin-roundcube-spamassassin-clamav-greylist-nginx-php5/

Je ne serai pas étonné qu'il existe une commande Debian toute faite
pour ça mais je ne l'ai pas trouvée.

Par contre j'ai trouvé ça :
http://howto.biapy.com/fr/debian-gnu-linux/serveurs/http/creer-un-certificat-ssl-sur-debian
mais ça ne parle pas de _remplacement_ des certificats existants
notamment ceux créés lors de la phase de post-installation du système
dont je ne suis pas sûr qu'il faille les remplacer.

Pour info j'accède à cette machine exclusivement par openvpn (Si
nécessaire, je peux la configurer pour temporairement accepter les connexions SSH hors
VPN).

Merci de vos éclairages qui m'éviteront à coups sûrs des ennuis et une
réinstallation complète de la bête et démêleront tout la confusion qui
règne dans ma tête sur ces sujet..

Ton truc est casse gueule (même le VPN seul, parce que le jour où
ton certificat OpenVPN va expirer, tu ne pourras plus te
connecter). J'ai quelque part un bout de code qui surveille OpenVPN
et qui redemande la configuration à partir du serveur à coup de
secret partagé si ça t'intéresse.

Commence par ouvrir le ssh avec un mot de passe, un fail2ban et si
tu es paranoïaque un knockd. Ça te permettra de travailler un peu
plus sereinement.

Pour OpenVPN, il faut que tu régénères les certificats avec les
scripts d'OpenVPN. Je ne suis pas sûr qu'OpenVPN fasse une
résolution DNS pour vérifier le nom des machines (en tout cas, j'ai
utilisé ça sur des réseaux assez tordus sans jamais n'avoir installé
de DNS).

Nginx, je ne connais que de nom.

Roundcube demande le certificat du serveur web. À régénérer. Au
pire, tu auras une alerte sur le nom de la machine. Cela n'empêchera
pas l'outil de fonctionner. Postfix, je ne sais pas trop comment il
gère la chose, je suis un dinosaure avec des écailles qui utilise
Sendmail.

Spamassassin / Clamav / Greylist n'utilisent pas à ma connaissance
de certificat.

Cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Le 17-01-2014, JKB nous expliquait dans
fr.comp.os.linux.configuration
(<slrnldjd8a.52b.jkb@rayleigh.systella.fr>) :

[SSH via openvpn]

Ton truc est casse gueule (même le VPN seul, parce que le jour où
ton certificat OpenVPN va expirer, tu ne pourras plus te
connecter).

De mémoire j'ai mis une date d'expiration suffisemment éloignée pour
être tranquille et au pire je peux reprendre la main sur la machine via
un système de secours (l'équivalent d'un rescue CD) et modifier
sshd_config.

J'ai quelque part un bout de code qui surveille OpenVPN
et qui redemande la configuration à partir du serveur à coup de
secret partagé si ça t'intéresse.

Pour le coup, ce ne sera pas nécessaire, merci.

Commence par ouvrir le ssh avec un mot de passe, un fail2ban et si
tu es paranoïaque un knockd. Ça te permettra de travailler un peu
plus sereinement.

Ça c'est c'est ce que je faisais avant mais j'avais des _milliers_ de
tentatives d'attaques quotidiennes en provenance de Chine (non, je n'ai
rien fait aux Chinois qui puissent me valoir un tel traitement et ma
dedibox, à usage privé, n'a donc aucune raison d'être visée).

Du coup avec ma solution j'ai un accès à ssh doublement sécurisé, il
faut faire partie du VPN _et_ avoir la clef RSA (donc 2 clefs
différentes) pour se connecter ce qui laisse tous ces gentils Chinois
(ne les fachons pas) devant un mur plutot que devant une porte qui
aussi verrouillée soit-elle finira par céder.

À l'occasion quand j'en ai le besoin, par exemple là tout de suite, je
revient temporairement sur l'ancienne config juste le temps de faire ma
grosse salade de certificats.

Pour OpenVPN, il faut que tu régénères les certificats avec les
scripts d'OpenVPN. Je ne suis pas sûr qu'OpenVPN fasse une
résolution DNS pour vérifier le nom des machines (en tout cas, j'ai
utilisé ça sur des réseaux assez tordus sans jamais n'avoir installé
de DNS).

Je ne crois pas non plus. De toutes façons à l'heure actuelle j'utilise
l'ancien certificat sans problème, c'est juste que cela ne me semble pas
'propre'. J'aime bien que les choses soient claires :-)

Nginx, je ne connais que de nom.

Pas mieux, je l'installe _uniquement_ parce que c'est dans le tutoriel.

J'ai suivi hier un autre tutoriel qui se contentait d'Apache mais arrivé
sur la configuration finale de dovecote et au moment de démarrer ce
dernier je me suis aperçu que le tutoriel était obsolète (il était pour
Squeeze, je pensais pouvoir adapter sans problème) au point que certains
fichiers de conf n'avaient plus du tout la même syntaxe !

Compte tenu de la complexité de l'empilement des couches, j'ai préféré
tout virer pour suivre un autre tutoriel. Celui-ci (indiqué dans mon
post iniial) semble pas mal. Concis mais complet.

L'idée pour moi est d'arriver à rapidement mettre en place une solution
complète et _fonctionnelle_ (il y aura des vrais users dessus) pour le
traitement des mails pour ensuite regarder en détail toute la config et
comprendre comment tout ça s'imbrique.

Roundcube demande le certificat du serveur web. À régénérer. Au
pire, tu auras une alerte sur le nom de la machine.

Oui, c'est ce que j'avais hier (j'avais mis en route le mode SSL
d'apache, c'est là que je me suis aperçu du problème).

C'est horriblment môche car, dans mon cas seamonkey, mais j'imagine que
c'est le cas de tous les navigateurs, affichait une alerte qui indiquait
que le certificat ne correspondait pas à la machine et me demandait
d'ajouter une exception, toussa.

L'ajout de l'exception ne me pose pas de problème (je ne vais pas payer
pour un certificat) mais l'affichage de l'ancien nom de domaine (qui ne
correspond vraiment plus du tout à ce qui est proposé aujourd'hui) est
vraiment très ennuyeux.

Un peu comme si un site sur l'abolition de la peine de mort demandait
l'acceptation d'un certifcat affichant le nom de domaine de la National
Riffle Assiociation. Bref, ça fait désordre ;-)

Cela n'empêchera
pas l'outil de fonctionner. Postfix, je ne sais pas trop comment il
gère la chose, je suis un dinosaure avec des écailles qui utilise
Sendmail.

Spamassassin / Clamav / Greylist n'utilisent pas à ma connaissance
de certificat.

Merci pour ces infos.

Cordialement,

Tout pareil, bon week-end.

--
Nous vivions nos vertiges dans des vibrations folles
Et gerbions nos enzymes en nous gueulant : moteur !
Mais entre deux voyages, entre deux verres d'alcool,
Nous n'avions pas le temps de décompter nos heures.
-- H.F. Thiéfaine, Exil Sur planète fantôme

Le Sat, 18 Jan 2014 10:41:32 +1100,
Doug713705 <doug.letough@free.fr> écrivait :

Le 17-01-2014, JKB nous expliquait dans
fr.comp.os.linux.configuration
(<slrnldjd8a.52b.jkb@rayleigh.systella.fr>) :

[SSH via openvpn]

Ton truc est casse gueule (même le VPN seul, parce que le jour où
ton certificat OpenVPN va expirer, tu ne pourras plus te
connecter).

De mémoire j'ai mis une date d'expiration suffisemment éloignée pour
être tranquille et au pire je peux reprendre la main sur la machine via
un système de secours (l'équivalent d'un rescue CD) et modifier
sshd_config.

J'ai quelque part un bout de code qui surveille OpenVPN
et qui redemande la configuration à partir du serveur à coup de
secret partagé si ça t'intéresse.

Pour le coup, ce ne sera pas nécessaire, merci.

Commence par ouvrir le ssh avec un mot de passe, un fail2ban et si
tu es paranoïaque un knockd. Ça te permettra de travailler un peu
plus sereinement.

Ça c'est c'est ce que je faisais avant mais j'avais des _milliers_ de
tentatives d'attaques quotidiennes en provenance de Chine (non, je n'ai
rien fait aux Chinois qui puissent me valoir un tel traitement et ma
dedibox, à usage privé, n'a donc aucune raison d'être visée).

C'est que fail2ban est mal configuré. Je subis aussi ces attaques,
mais les seuls logs qui enflent sont ceux de fail2ban (je ne bannis
pas que l'adresse IP mais tout le sous-réseau). Je n'ai même pas
installé de knockd parce qu'il se baugeait sur un SIGBUS sur mes
sparcs. Sur mes machines vraiment critiques, je n'ouvre l'accès ssh
qu'à partir d'adresses IP parfaitement connues. Lorsque je suis en
déplacement, il faut déjà que je me connecte sur une machine avec
un ssh ouvert sur le grand monde avant de rebondir sur mes machines
critiques.

Du coup avec ma solution j'ai un accès à ssh doublement sécurisé, il
faut faire partie du VPN _et_ avoir la clef RSA (donc 2 clefs
différentes) pour se connecter ce qui laisse tous ces gentils Chinois
(ne les fachons pas) devant un mur plutot que devant une porte qui
aussi verrouillée soit-elle finira par céder.

Et ça peut aussi te mettre dans la mouise rapidement, mais c'est toi
qui vois. De toute façon, les attaques les plus intéressantes ne
passeront pas par le ssh, mais par tes serveurs web avec ton php.
Pour ma part, je préfère un ssh ouvert sur une machine tant soit peu
sécurisée qu'une machine accessible par OpenVPN.

À l'occasion quand j'en ai le besoin, par exemple là tout de suite, je
revient temporairement sur l'ancienne config juste le temps de faire ma
grosse salade de certificats.

Pour OpenVPN, il faut que tu régénères les certificats avec les
scripts d'OpenVPN. Je ne suis pas sûr qu'OpenVPN fasse une
résolution DNS pour vérifier le nom des machines (en tout cas, j'ai
utilisé ça sur des réseaux assez tordus sans jamais n'avoir installé
de DNS).

Je ne crois pas non plus. De toutes façons à l'heure actuelle j'utilise
l'ancien certificat sans problème, c'est juste que cela ne me semble pas
'propre'. J'aime bien que les choses soient claires :-)

Nginx, je ne connais que de nom.

Pas mieux, je l'installe _uniquement_ parce que c'est dans le tutoriel.

J'ai suivi hier un autre tutoriel qui se contentait d'Apache mais arrivé
sur la configuration finale de dovecote et au moment de démarrer ce
dernier je me suis aperçu que le tutoriel était obsolète (il était pour
Squeeze, je pensais pouvoir adapter sans problème) au point que certains
fichiers de conf n'avaient plus du tout la même syntaxe !

Compte tenu de la complexité de l'empilement des couches, j'ai préféré
tout virer pour suivre un autre tutoriel. Celui-ci (indiqué dans mon
post iniial) semble pas mal. Concis mais complet.

L'idée pour moi est d'arriver à rapidement mettre en place une solution
complète et _fonctionnelle_ (il y aura des vrais users dessus) pour le
traitement des mails pour ensuite regarder en détail toute la config et
comprendre comment tout ça s'imbrique.

Roundcube demande le certificat du serveur web. À régénérer. Au
pire, tu auras une alerte sur le nom de la machine.

Oui, c'est ce que j'avais hier (j'avais mis en route le mode SSL
d'apache, c'est là que je me suis aperçu du problème).

C'est horriblment môche car, dans mon cas seamonkey, mais j'imagine que
c'est le cas de tous les navigateurs, affichait une alerte qui indiquait
que le certificat ne correspondait pas à la machine et me demandait
d'ajouter une exception, toussa.

Tu auras de toute façon l'exception si le certificat n'est pas signé
par un CA officiel.

L'ajout de l'exception ne me pose pas de problème (je ne vais pas payer
pour un certificat) mais l'affichage de l'ancien nom de domaine (qui ne
correspond vraiment plus du tout à ce qui est proposé aujourd'hui) est
vraiment très ennuyeux.

Un peu comme si un site sur l'abolition de la peine de mort demandait
l'acceptation d'un certifcat affichant le nom de domaine de la National
Riffle Assiociation. Bref, ça fait désordre ;-)

Cela n'empêchera
pas l'outil de fonctionner. Postfix, je ne sais pas trop comment il
gère la chose, je suis un dinosaure avec des écailles qui utilise
Sendmail.

Spamassassin / Clamav / Greylist n'utilisent pas à ma connaissance
de certificat.

Merci pour ces infos.

Cordialement,

Tout pareil, bon week-end.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Doug713705 , dans le message <fvmoqax857.ln2@actarus.bourzy.lan>, a
écrit :

- sshd (authentification par clefs RSA)

Je ne sais pas trop ce qu'il en est des autres (sauf tout ce dont je sais
que c'est du TLS, évidemment), mais pour SSH, la clef est clairement une
propriété du serveur lui-même et n'est pas du tout reliée au nom DNS.

Il vaut même mieux conserver la clef, de sorte à prouver que c'est bien le
même serveur qui a changé de nom.

Le 17-01-2014, Doug713705 nous expliquait dans
fr.comp.os.linux.configuration
(<fvmoqax857.ln2@actarus.bourzy.lan>) :

Cependant il me reste à remplacer les certificats afin qu'ils
correspondent également à ce nouveau nom de domaine mais avant de faire
une bêtise et de me retrouver dans une impasse inextricable j'aimerai
être sûr de ne rien oublier mais également de faire les choses dans
le bon ordre.

Je les ai finalement remplacés un par un au cas par cas avant de
comprendre (et encore je ne suis même pas sûr de moi) que la plupart
sinon tous sont liés à /etc/ssl/certs/ssl-cert-snakeoil.pem
que j'ai finalement remplacé par une certificat auto-signé de mon cru.

Pas sûr que celà soit suffisant, si un pro de la sécurité pouvait
m'expliquer l'utilité exacte de ce certificat que, ne sachant pas qu'il
existait, j'ai eu un mal fou à localiser.

Je l'ai donc remplacé à la méthode 'bourrin' mais avant cela j'avais
déjà modifié tous les fichiers de conf des différents services pour
qu'ils utilisent un autre certificat que celui-ci qui revenait sans
cesse malgré mes modifications.

Je ne suis pas sur d'être clair mais ma question est simple :
Est-ce que d'avoir remplacé /etc/ssl/certs/ssl-cert-snakeoil.pem
par un certificat auto-signé généré avec la commande

openssl req -new -x509 -days 3650 -nodes -out
/etc/ssl/certs/ssl-cert-snakeoil.pem -keyout
/etc/ssl/certs/private/ssl-cert-snakeoil.key [1]

est suffisant, sûre et ne nuira pas au bon fonctionnement du serveur à
l'avenir notamment lors de l'éventuelle installation future d'un
nouveau service.

[1] oui, j'ai mis une validité de 10 ans et j'ai créé une autorité de
certification perso.

--
Veuillez dégager le vide-ordures s'il vous plaît,
et ne pas laisser les enfants s'amuser avec les fils à haute tension.
Tout corps vivant branché sur le secteur étant appelé à s'émouvoir
-- H.F. Thiéfaine, L'ascenceur de 22H43

Le 18-01-2014, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<52dab3b3$0$2270$426a74cc@news.free.fr>) :

Doug713705 , dans le message <fvmoqax857.ln2@actarus.bourzy.lan>, a
écrit :

- sshd (authentification par clefs RSA)

Je ne sais pas trop ce qu'il en est des autres (sauf tout ce dont je sais
que c'est du TLS, évidemment), mais pour SSH, la clef est clairement une
propriété du serveur lui-même et n'est pas du tout reliée au nom DNS.

Il vaut même mieux conserver la clef, de sorte à prouver que c'est bien le
même serveur qui a changé de nom.

C'est le seul que je n'ai pas osé changer, justement pour cette raison.

Il me reste à remplacer celui d'openvpn mais ce n'est pas vraiment un
problème puisque le principe est le même que lors de la configuration
initiale. Et pour le coup il n'y a pas d'urgence et ça n'a pas vraiment
d'importance à mes yeux.

Ça risque donc de rester en l'état.

--
Alors je me mets à rêver
Que je suis un slip de carmélite
Que personne ne peut me toucher
Sans se noyer dans l'eau bénite
-- H.F. Thiéfaine, La queue

Doug713705 wrote:

(snip)

[1] oui, j'ai mis une validité de 10 ans et j'ai créé une autorité de
certification perso.

plutôt que de faire ça demande un certificat gratuit sur startssl par
exemple. Ce sera aussi peu sécurisant pour le client mais au moins le
navigateur n'enverra pas d'exception de sécurité à tout va.

Le 19-01-2014, laurent nous expliquait dans
fr.comp.os.linux.configuration
(<52db9f48$0$2214$426a74cc@news.free.fr>) :

Doug713705 wrote:

(snip)

[1] oui, j'ai mis une validité de 10 ans et j'ai créé une autorité de
certification perso.

plutôt que de faire ça demande un certificat gratuit sur startssl par
exemple. Ce sera aussi peu sécurisant pour le client mais au moins le
navigateur n'enverra pas d'exception de sécurité à tout va.

J'ai mal à la tête rien qu'à la vue de ce qu'il faut lire et accepter pour
obtenir le certificat...

Dans le millionnième de ce temps, j'ai généré mon certificat tout beau
tout neuf comme je veux avec des petits morceaux d'humour dedans ;-)

Cependant, l'idée d'une autorité reconnue qui fourni gratuitement un
certificat est bonne.

--
Car moi je n'irai pas plus loin.
Je tiens ma tête entre mes mains.
Guignol connaît pas de sots métiers.
Je ris à m'en faire crever !
H.F. Thiéfaine- 113ème Cigarette Sans Dormir

Doug713705 <doug.letough@free.fr> écrivait :

Cependant, l'idée d'une autorité reconnue qui fourni gratuitement un
certificat est bonne.

L'idée d'une "autorité reconnue" qui peut signer tout et n'importe quoi
est la faille majeure de SSL.

Il faut passer à DANE.

--
Les simplifications c'est trop compliqué

Le 19-01-2014, Erwan David nous expliquait dans
fr.comp.os.linux.configuration
(<878uucz1xa.fsf@bibi.depot.rail.eu.org>) :

Doug713705 <doug.letough@free.fr> écrivait :

Cependant, l'idée d'une autorité reconnue qui fourni gratuitement un
certificat est bonne.

L'idée d'une "autorité reconnue" qui peut signer tout et n'importe quoi
est la faille majeure de SSL.

Je ne connais rien au process de la signature d'un certificat payant,
,genre verisign, mais à part le chèque quelle est la vraie différence
avec l'espèce de fausse SARL étrangère qui refile du certificat en
veux-tu en voilà ?

Il faut passer à DANE.

Pourquoi pas

--
En ce temps-là, les gens s'appelaient citoyens.
Nous, nous étions mutants, nous étions androgynes.
Aujourd'hui, la tempête a lynché mes copains
Et je suis le dernier à rater mon suicide.
-- H.F. Thiéfaine, Exil Sur planète fantôme