2026-10-22-Local-home.arpa

2026-10-22-Local-home.arpa

Notes

“.home.arpa” est un nom de domaine à usage spécial qui est désigné pour une utilisation non unique dans les réseaux domestiques résidentiels (c’est-à-dire non autorisé sur l’Internet public). Il a toujours besoin d’un serveur DNS privé pour la résolution des noms d’hôtes.

Informations

.local est utilisé par mDNS (multicast DNS), un protocole conçu par Apple. Utiliser exemple.local ne fonctionne que sur les systèmes (et pour les destinations) qui ont un démon mDNS en cours d’exécution (par exemple MacOSX, distributions Linux actuelles comme Ubuntu/Fedora).

  • “.home.arpa” est un nom de domaine à usage spécial qui est désigné pour une utilisation non unique dans les réseaux domestiques résidentiels (c’est-à-dire non autorisé sur l’Internet public). Il a toujours besoin d’un serveur DNS privé pour la résolution des noms d’hôtes.
  • “.local” est un nom de domaine à usage spécial qui peut fonctionner sans serveur DNS local (c’est-à-dire privé).

Le home.arpa spTLD n’est pas un nom de domaine unique à l’échelle mondiale, et vous ne pouvez pas le résoudre sur Internet. Il est destiné uniquement à être utilisé à l’intérieur d’un petit réseau, comme votre réseau domestique. Les routeurs et les serveurs du système de noms de domaine (DNS) savent, [en théorie], ne pas transmettre les demandes ARPA qu’ils ne comprennent pas sur Internet public.

Domaine home.arpa

Autorité de Certification (AC)

En cryptographie, une Autorité de Certification (AC ou CA pour Certificate Authority en anglais) est un tiers de confiance permettant d’authentifier l’identité des correspondants. Une autorité de certification délivre des certificats décrivant des identités numériques et met à disposition les moyens de vérifier la validité des certificats qu’elle a fournis.
Les services des autorités de certification sont principalement utilisés dans le cadre de la sécurisation des communications numériques via le protocole Transport Layer Security (TLS) utilisé par exemple pour sécuriser les communications web (HTTPS) ou email (SMTP, POP3, IMAP… sur TLS), ainsi que pour la sécurisation des documents numériques (par exemple au moyen de signatures électroniques avancées telles que PAdES pour des documents PDF, ou via le protocole S/MIME pour les e-mails).
[Citation wikipédia Autorité de certification]

Utilisation de l’application OpenSSL qui est installée par défaut sur toutes les distributions linux

Créer une Autorité de Certification nommée homearpaCA
Créer le dossier

1
2

mkdir $HOME/homearpaCA
cd $HOME/homearpaCA

Procédure

  • Générer une autorité de certification (AC) pour usage privé
  • Générer un certificat SSL pour un domaine
  • Paramétrer les services concernés : Nginx
  • Quelques abréviations:
    • CA :
      • Certificate Authority
      • Autorité de Certification
    • KEY :
      • Private key
      • Clé privée
    • CSR :
      • Certificate Signing Request
      • Demande de Signature de Certificat
    • CN :
      • Common Name
      • Nom Commun (nom pleinement qualifié dans le cas du certificat client)
    • CRT :
      • Certificat

On va générer des certificats pour un domaine interne home.arpa.
Il sera nécessaire, pour que le certificat soit reconnu officiellement, d’ajouter le CA dans le magasin de certificat du système.

Clé homearpaCA.key

On commence par le plus important, la clé privé de votre autorité de certification. Elle sera à préserver de tout (vol, perte, suppression, etc ).

C’est elle qui vous permettra de signer de nouveaux certificats.

1

openssl genrsa -out homearpaCA.key

Certificats racines homearpaCA

homearpaCA.pem

Maintenant qu’on a la clé, on va générer le certificat racine homearpaCA.pem :

1

openssl req -x509 -new -nodes -key homearpaCA.key -sha256 -days 7300 -subj "/C=FR/ST=PAYS-DE-LOIRE/L=BOPRO/O=HOMEARPA/OU=HOMEARPA/CN= HOMEARPA CA" -out homearpaCA.pem

Note : L’option -subj permet d’éviter de répondre à un certain nombre de questions. On génère le certificat pour une durée de 20 ans (7300).

homearpaCA.crt

Générer un certificat au format crt en plus du pem pour l”autorité de certification CA

1

openssl x509 -in homearpaCA.pem -inform PEM -out homearpaCA.crt

Nous avons maintenant 3 fichiers :

  • homearpaCA.key => La clé privée
  • homearpaCA.pem => Certificat racine au format pem
  • homearpaCA.crt => Certificat racine au format crt

Copie homearpaCA crt et key

Copier les fichiers homearpaCA.key et homearpaCA.crt dans /etc/ssl/private/

1
2

sudo cp homearpaCA.key /etc/ssl/private/
sudo cp homearpaCA.crt /etc/ssl/private/

Déployer Autorité Certification

Les certificats d’AC nous aident à identifier et à faire confiance aux autres parties. Lorsqu’un tiers envoie un certificat, le client qui le reçoit valide le certificat.
Tout d’abord, le client récupère la clé publique de cette autorité de certification particulière qui a signé le certificat, à partir de son magasin de confiance. Il décrypte ensuite la signature présente dans le certificat du tiers pour obtenir une valeur de hachage.
Ensuite, le client calcule indépendamment le hachage à l’aide des données du certificat client et le compare avec la valeur de hachage déchiffrée. Si elle correspond, le tiers est digne de confiance. En général, la vérification du certificat se fait de cette manière.

Pour que vos certificats *.home.arpa soient reconnus, il faut installer le certificat racine de votre CA (homearpaCA.crt ou équivalent, pas la clé .key) dans le magasin d’AC de confiance du système ou du navigateur.

Red Hat, CentOS, Alma Linux, Rocky

Red Hat, CentOS, Alma Linux, Rocky: https://www.linuxtricks.fr/wiki/red-hat-centos-alma-linux-rocky-ajouter-une-autorite-de-certification-au-magasin-systeme

Debian distributions

Copier le certificat

1
2

sudo mkdir -p /usr/local/share/ca-certificates
sudo cp homearpaCA.crt /usr/local/share/ca-certificates/

Mettre à jour le magasin de certificats :

1

sudo update-ca-certificates

Un message indique qu’un certificat a été ajouté :

1
2
3
4
5

Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt, it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done

Vérifier que le certificat a bien été ajouté en vérifiant qu’un .pem a été créé dans /etc/ssl/certs :

1

ls /etc/ssl/certs/ | grep -i homearpa

Archlinux, Manjaro, EndeavourOS

Pour des clients ArchLinux ça se fait alors avec la commande trust

1
2

# en mode su
trust anchor --store homearpaCA.crt

On peut vérifier qu’il est bien dans la liste à partir de son nom: trust list | rg -C 2 "HOMEARPA"

1
2
3
4
5

pkcs11:id=%9E%E4%56%A9%A1%3D%7D%54%3D%76%65%14%DD%E1%40%6D%D1%36%85%F7;type=cert
    type: certificate
    label:  HOMEARPA CA
    trust: anchor
    category: authority

On en profite pour bien vérifier que le certificat est un certificat d’autorité (catégorie authority) et bien sûr que ce soit bien un certificat (type certificate).

Il est alors installé dans le dossier /etc/ca-certificates/trust-source/.

1
2
3
4
5

/etc/ca-certificates/trust-source/
├── anchors
├── blocklist
├── _HOMEARPA_CA.p11-kit
└── README

Pour supprimer le certificat des certificats de confiance, on utilise le fichier généré dans ce dossier.

1
2

# en mode su
trust anchor --remove /etc/ca-certificates/trust-source/_HOMEARPA_CA.p11-kit

Alpine Linux

Sur Alpine et d’autres distributions Linux telles que Debian, un utilitaire de paquets appelé ca-certificatesca-certificats comprend une collection de certificats de confiance des autorités de certification. Ces certificats vérifient l’identité des sites Web auxquels nous nous connectons sur les connexions SSL (TLS).

Bien sûr, nous devons mettre à jour cette collection avec n’importe quel certificat nouvellement créé. La collection de certificats de confiance réside dans le fichier /etc/ssl/certs/ca-certificates.crt. Nous pouvons mettre à jour ce magasin de confiance en ajoutant des certificats individuels situés dans le répertoire /usr/local/share/ca-certificates/.

Mettre à jour les paquets et installer ca:

1

sudo apk update && sudo apk add ca-certificates

En outre, il est recommandé de nettoyer le cache apk avant de mettre à jour la collection de certificats:

1

sudo rm -rf /var/cache/apk/*

Ensuite, nous copions server.crt aux /usr/local/share/ca-certificates/ :

1

sudo cp docker-data/homearpaCA.crt /usr/local/share/ca-certificates/

Enfin, nous pouvons ajouter le certificat à la collection de ca-certificats en utilisant la commande update-ca-certificates:

1

sudo update-ca-certificates

Vérifier les mises à jour au bas du fichier.

1

tail -25 /etc/ssl/certs/ca-certificates.crt

Firefox (OBLIGATOIRE)

Firefox utilise UNIQUEMENT son propre magasin (base cert9.db).

Importer uniquement dans Firefox

  1. about:preferences#connectionSecurity dans la barre d’adresse.
  2. Descendez à la section « Certificats ».
  3. Cliquez sur « Gérez les certificats ».
  4. Onglet « Autorités ».
  5. Cliquez sur « Importer » et choisissez homearpaCA.crt.
  6. Cochez au minimum « Identifier des sites web » puis validez.

Paramètres –> Vie privée et sécurité

Certificat wildcard *.home.arpa

Un certificat SSL Wildcard permet de sécuriser un domaine principal et tous ses sous-domaines avec un seul certificat, offrant ainsi flexibilité et simplicité de gestion

OpenSSL pour générer un certificat wildcard *.home.arpa signé par la CA (Autorité de Certification) locale dont la clé privée est homearpaCA.key (et le certificat homearpaCA.crt).

  • Clé de la CA : /etc/ssl/private/homearpaCA.key
  • Certificat de la CA : /etc/ssl/private/homearpaCA.crt
  • Dossier pour le wildcard : /etc/ssl/home.arpa/

Clé privée pour le wildcard

En mode su (serveur cwwk)

1
2
3
4
5
6

mkdir -p /etc/ssl/home.arpa
cd /etc/ssl/home.arpa

# clé privée RSA 2048 bits pour le certificat wildcard
openssl genrsa -out wildcard.home.arpa.key 2048
chmod 600 wildcard.home.arpa.key

Créer fichier pour les extensions (SAN)

Pour que les navigateurs modernes acceptent le wildcard, il faut un champ Subject Alternative Name (SAN).

Créer /etc/ssl/home.arpa/wildcard.home.arpa.ext :

1
2
3
4
5
6
7
8
9

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.home.arpa
DNS.2 = home.arpa

Générer CSR pour *.home.arpa

1
2
3
4
5

cd /etc/ssl/home.arpa

openssl req -new -key wildcard.home.arpa.key \
  -out wildcard.home.arpa.csr \
  -subj "/C=FR/ST=Pays-de-la-Loire/L=Beaupreau/O=HomeLab/CN=*.home.arpa"
  • Le CN est *.home.arpa.
  • Les SAN sont ajoutés au moment de la signature (prochaine étape) via le fichier .ext

Signer CSR avec AC homearpaCA

Autorité de Certification:

  • Clé CA : /etc/ssl/private/homearpaCA.key
  • Certificat CA : /etc/ssl/private/homearpaCA.crt
1
2
3
4
5
6
7
8
9
10
11
12
13

cd /etc/ssl/home.arpa

openssl x509 -req \
  -in wildcard.home.arpa.csr \
  -CA /etc/ssl/private/homearpaCA.crt \
  -CAkey /etc/ssl/private/homearpaCA.key \
  -CAcreateserial \
  -out wildcard.home.arpa.crt \
  -days 3650 \
  -sha256 \
  -extfile wildcard.home.arpa.ext
  # Si passphrase homearpaCA.key
  #Enter pass phrase for /etc/ssl/private/homearpaCA.key:

Au final:

  • wildcard.home.arpa.crt : certificat serveur wildcard signé par votre CA
  • wildcard.home.arpa.key : clé privée correspondante

Information sur le role du fichier 'wildcard.home.arpa.ext'
Le fichier wildcard.home.arpa.ext n’est jamais vu ni interprété par les navigateurs : il ne sert qu’au moment où vous signez le certificat avec OpenSSL pour y injecter les extensions (SAN, usages, etc.)
Rôle réel du .ext, lorsque vous lancez la commande de signature, vous faites quelque chose comme :

1
2
3
4
5
6

openssl x509 -req \
  -in wildcard.home.arpa.csr \
  -CA homearpaCA.crt \
  -CAkey homearpaCA.key \
  -out wildcard.home.arpa.crt \
  -extfile wildcard.home.arpa.ext
  • OpenSSL lit wildcard.home.arpa.ext et copie son contenu dans le certificat final wildcard.home.arpa.crt (dans les champs « X509v3 extensions »)
  • Le navigateur, lui, ne connaît que le certificat présenté par le serveur (le .crt) et lit ses extensions déjà intégrées

Donc :

  • Le .ext est un fichier intermédiaire de génération, purement côté serveur/admin.
  • Les navigateurs ne le téléchargent pas, ne le parsèment pas, ne savent même pas qu’il existe.

Ce que voient réellement les navigateurs

Les navigateurs valident, dans le certificat fini (wildcard.home.arpa.crt) :

  • Le sujet / CN : ici *.home.arpa.
  • Le champ Subject Alternative Name (SAN) : par exemple DNS:*.home.arpa et DNS:home.arpa.
  • Les extensions comme Key Usage, Extended Key Usage, Basic Constraints, etc.

Tout cela vient du contenu du .ext, mais une fois « compilé » dans le certificat, c’est totalement opaque pour le client que ça provenait d’un fichier séparé.

En résumé :

  • Le navigateur ne tient jamais compte de /etc/ssl/home.arpa/wildcard.home.arpa.ext directement.
  • Il tient compte uniquement du certificat TLS que Nginx lui présente.
  • Le .ext n’est qu’un moyen pratique de contrôler ce qui sera écrit dans ce certificat (SAN, usages, etc.).

Vérifier certificat wildcard.home.arpa.crt

1

openssl x509 -in wildcard.home.arpa.crt -noout -text | less

Analyse

1
2
3
4
5
6
7
8
9

[...]
        Subject: C=FR, ST=Pays-de-la-Loire, L=Beaupreau, O=HomeLab, CN=*.home.arpa
        Subject Public Key Info:
            X509v3 Subject Alternative Name: 
            X509v3 Subject Key Identifier: 
[...]
            X509v3 Subject Alternative Name: 
                DNS:*.home.arpa, DNS:home.arpa
[...]

Vérifiez bien :

  • Le Subject avec CN = *.home.arpa
  • La section X509v3 Subject Alternative Name contenant DNS:*.home.arpa et DNS:home.arpa

Vous pouvez ensuite les utiliser sur votre reverse proxy / services, en vous assurant que le certificat homearpaCA.crt est installé comme autorité de confiance sur tous les clients.