Bonjour à toutes, tous,
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..
Bonjour à toutes, tous,
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..
Bonjour à toutes, tous,
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,
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,
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,
Le 17-01-2014, JKB nous expliquait dans
fr.comp.os.linux.configuration
() :
[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.
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.
Le 17-01-2014, JKB nous expliquait dans
fr.comp.os.linux.configuration
() :
[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.
- sshd (authentification par clefs RSA)
- sshd (authentification par clefs RSA)
- sshd (authentification par clefs RSA)
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.
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.
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.
Doug713705 , dans le message , 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.
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.
Doug713705 , dans le message , 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.
[1] oui, j'ai mis une validité de 10 ans et j'ai créé une autorité de
certification perso.
[1] oui, j'ai mis une validité de 10 ans et j'ai créé une autorité de
certification perso.
[1] oui, j'ai mis une validité de 10 ans et j'ai créé une autorité de
certification perso.
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.
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.
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.
Cependant, l'idée d'une autorité reconnue qui fourni gratuitement un
certificat est bonne.
Cependant, l'idée d'une autorité reconnue qui fourni gratuitement un
certificat est bonne.
Cependant, l'idée d'une autorité reconnue qui fourni gratuitement un
certificat est bonne.
Doug713705 é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.
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.
Doug713705 é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.
