Post

Domaine home.arpa

Posté
Preview Image
Par Yann
17 min lire
Domaine home.arpa

“.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.

home.arpa

Liens

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.

Gérer un domaine local avec Unbound

Gérer un domaine local avec Unbound, créer un domaine local, pour le réseau privé, ce qui est bien plus pratique que de retenir des IPs ou maintenir un fichier hosts sur les machines où l’on y a accès

On liste les appareils du réseau et on note leurs adresses IPv4 et IPv6 (si cette dernière est fixe) pour passer le tout à Unbound.

Création configuration local-unbound.conf
On crée donc un fichier de configuration dans /etc/unbound/unbound.conf.d/ (sous Debian & dérivés. Pour les systèmes type Arch, on peut mettre cela dans le fichier de configuration principal ou bien dans un fichier à part que l’on inclut dans la conf principale via include) et on y ajoute :

Configuration des accès réseaux locaux dans le fichier /etc/unbound/unbound.conf.d/local-unbound.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

server:
    # Adresse privée 
    access-control: 192.168.0.0/16 allow
    access-control: 192.168.10.0/16 allow
    access-control: 192.168.70.0/16 allow
    #
    local-zone: "home.arpa." transparent
    #local-zone: "home.arpa." static
    # IPv4
    local-data: "cwwk.home.arpa.  86400 IN A 192.168.0.205"
    local-data: "pve.home.arpa.  86400 IN A 192.168.0.205"
    local-data: "cockpit.home.arpa.  86400 IN A 192.168.0.205"
    local-data: "alp01.home.arpa. 86400 IN A 192.168.10.210"
    local-data: "centreon.home.arpa.  86400 IN A 192.168.0.29"
    # IPv6
    local-data: "cwwk.home.arpa.  86400 IN AAAA 2a01:e0a:9c8:2080:aab8:e0ff:fe04:ec45"
    local-data: "pve.home.arpa.  86400 IN AAAA 2a01:e0a:9c8:2080:aab8:e0ff:fe04:ec45"
    # On ajoute les enregistrements PTR
    # PTR IPv4
    local-data-ptr: "192.168.0.205  86400 cwwk.home.arpa."
    local-data-ptr: "192.168.0.205  86400 pve.home.arpa."
    local-data-ptr: "192.168.0.205  86400 cockpit.home.arpa."
    local-data-ptr: "192.168.10.210 86400 alp01.home.arpa."
    local-data-ptr: "192.168.10.29 86400 centreon.home.arpa."
    # PTR IPv6
    local-data-ptr: "2a01:e0a:9c8:2080:aab8:e0ff:fe04:ec45  86400 cwwk.home.arpa."
    local-data-ptr: "2a01:e0a:9c8:2080:aab8:e0ff:fe04:ec45  86400 pve.home.arpa."
    local-data-ptr: "2a01:e0a:9c8:2080:aab8:e0ff:fe04:ec45  86400 cockpit.home.arpa."

Explications

  • Le type transparent de local-zone a le fonctionnement suivant : si le domaine est listé dans les local-data, Unbound répond avec ces données ou NODATA si l’enregistrement demandé ne s’y trouve pas. Le mécanisme de résolution normal est utilisé si le domaine ne possède aucune donnée locale. Il est utilisé si on héberge une sonde RIPE Atlas, le résolveur peut-être utilisé pour des tests et notamment des requêtes demanant le SOA de home.arpa. (qui est un enregisrement qui existe dans les véritables NS du domaine). Donc, pour essayer d’éviter de révéler que ce domaine est utilisé localement, transparent me semble une bonne solution.
  • Sans cette contrainte, le type static est parfaitement adapté (le résolveur intercepte toutes requêtes pour tout l’arbre home.arpa., sert les données qu’il possède sinon répond NODATA ou NXDOMAIN).
  • On peut ajouter tout type d’enregistrements — non liés à DNSSEC. On peut donc mettre un enregistrement TXT pour chaque machine qui fournirait une petite description de celle-ci. Exemple, si un domaine test.home.arpa est vide car il ne contient que des sous-domaines comme par exemple dm1.test.home.arpa,dm1.test.home.arpa , les requêtes pour ce parent suivraient le mécanisme de résolution récursif.
    Attention à la syntaxe pour ajouter un enregistrement TXT : utilisation de guillemets simples pour l’enregisrement complet et double pour le texte à passer.
1
2
3
4

local-data: "dm1.test.home.arpa.  86400 IN A 192.168.0.3"
local-data: "dm2.test.home.arpa.  86400 IN A 192.168.0.4"
[...]
local-data: 'test.home.arpa.  86400 IN TXT "Une adresse par interface"'

Vérifications
Vérifier la configuration

1

sudo unbound-checkconf /etc/unbound/unbound.conf.d/local-unbound.conf

unbound-checkconf: no errors in /etc/unbound/unbound.conf.d/local-unbound.conf

Redémarrer Unbound

1

systemctl restart unbound

on peut faire quelques tests

1

dig cwwk.home.arpa


1

dig -x 192.168.0.205

On a dans les 2 exemples précédents, l’indication aa(Authoritative Answer) dans les réponses. Le résolveur fait donc autorité et nous a bien servi les enregistrements configurés.

1

dig SOA home.arpa

Cette fois-ci, pas de bit AA dans la réponse, Unbound est donc allé chercher la réponse via le mécanisme récursif habituel.

Autre domaine

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

[yann@PC1 ~]$ dig pve.home.arpa

; <<>> DiG 9.20.8 <<>> pve.home.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49510
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pve.home.arpa.			IN	A

;; ANSWER SECTION:
pve.home.arpa.		86400	IN	A	192.168.0.205

;; Query time: 1 msec
;; SERVER: 192.168.0.205#53(192.168.0.205) (UDP)
;; WHEN: Sun May 11 13:22:45 CEST 2025
;; MSG SIZE  rcvd: 58

[yann@PC1 ~]$ dig -x 192.168.0.205

; <<>> DiG 9.20.8 <<>> -x 192.168.0.205
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41645
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;205.0.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
205.0.168.192.in-addr.arpa. 86400 IN	PTR	cwwk.home.arpa.
205.0.168.192.in-addr.arpa. 86400 IN	PTR	pve.home.arpa.

;; Query time: 1 msec
;; SERVER: 192.168.0.205#53(192.168.0.205) (UDP)
;; WHEN: Sun May 11 13:23:07 CEST 2025
;; MSG SIZE  rcvd: 97

Création Autorité de Certification interne

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

Introduction

  • 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 : Ngnix
  • 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é du CA

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

Certificat racine 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).

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

Déployer le CA sur les systèmes d’exploitation

How to Add, Remove, and Update CA Certificates in Linux

On peut d’ores et déjà installer le CA autosigné chez les clients

Ajouter une autorité de certification au magasin système

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

Firefox : Ajouter une autorité de certification au magasin local : https://www.linuxtricks.fr/wiki/firefox-ajouter-une-autorite-de-certification-au-magasin-local

Debian distributions

Debian distributions :
Copier le certificat

1

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

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

Générer les certificats clients sur la machine cwwk

Le script gencert.sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139

#!/bin/bash

# Test an IP address for validity:
# Usage:
#      valid_ip IP_ADDRESS
#      if [[ $? -eq 0 ]]; then echo good; else echo bad; fi
#   OR
#      if valid_ip IP_ADDRESS; then echo good; else echo bad; fi
#
function valid_ip()
{
    #local  ip=$2
    local  stat=1

    if [[ $ip =~ ^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$ ]]; then
        OIFS=$IFS
        IFS='.'
        ip=($ip)
        IFS=$OIFS
        [[ ${ip[0]} -le 255 && ${ip[1]} -le 255 \
            && ${ip[2]} -le 255 && ${ip[3]} -le 255 ]]
        stat=$?
    fi
    return $stat
}


#################################################################
#
# DEPART SCRIPT
#
# Générateur de certificat pour le domaine local home.arpa
# si le fichier local-unbound.conf n'existe pas, on sort du script
if [ ! -f "/etc/unbound/unbound.conf.d/local-unbound.conf" ] || [ "`hostname`" != "cwwk" ]; then
    echo "local-unbound.conf n'existe pas ou le hostname n'est pas 'cwwk'"
    exit 1
fi

# Vérifier si argument
if [ $# -ne 2 ]
  then 
    echo "Générateur de certificat pour le <sous-domaine>.home.arpa"
    echo "---------------------------------------------------------"
    echo "2 arguments sont nécessaires"
    echo "Syntaxe: gencert <sous-domaine> <adresse IP>"
    echo "Supprimer certificat existant"
    echo "Syntaxe: gencert <sous-domaine> delete"
    exit 0
fi

# si argument "delete" on ne vérifie pas adresse ip
if ! [[ "$2" == "delete" ]]; then
	# Si adresse ip non valide , on sort
	ip=$2
	if ! (valid_ip $ip)
	then 
	 echo "erreur format adresse IP !!!"
	 exit 1
	fi
fi

# Chemin des fichiers crt et key du CA 
CA="$HOME/homearpaCA/homearpaCA"

# Domaine du CA
DOMAINE="home.arpa"
# dossier des fichiers .key et .crt
CADOSSIER="/etc/ssl/private"
if [ ! -d "$CADOSSIER" ]; then
  echo "Dossier $CADOSSIER inexistant!"
  exit 1
fi
# Fichier de configuration Unbound
CFGUNBOUND="/etc/unbound/unbound.conf.d/local-unbound.conf"
# Vérifier si le certificat du  sous-domaine  existe?
if [ -f "$CADOSSIER/$1.home.arpa.crt" ]; then
	# certificat du  sous-domaine existe, suppression ?
	argument=("$@")
	if [ -n "${argument[1]}" ]; then
	 # second argument = delete ?
	 if [[ "$2" == "delete" ]]; then
	    echo "Supprimer certificat $1"
	    CFGDEL=$1
	    sudo rm $CADOSSIER/$CFGDEL.home.arpa.*
	    sudo sed -i '/$CFGDEL.home.arpa/d' $CFGUNBOUND 
	    sudo systemctl restart unbound
	    sudo rm /etc/nginx/conf.d/$CFGDEL.*
	    sudo systemctl reload nginx
	    exit 0
	 fi
	else
    echo "Le certificat du sous-domaine $1 existe !!!"
    exit 0	  
	fi
fi
################
# DEBUT SCRIPT #
################
# Validate domain name
validate="^([a-zA-Z0-9][a-zA-Z0-9-]{0,61}[a-zA-Z0-9]\.)+[a-zA-Z]{2,}$"
FQDN="$1.$DOMAINE"
if [[ "$FQDN" =~ $validate ]]; then
    echo "Domaine $FQDN"
else
    echo "Invalide domaine $FQDN"
    exit 1
fi
echo "Certificat pour : $FQDN"
echo "Fichier de directives de configuration"
cat > $FQDN.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = $FQDN
EOF
echo "Generation KEY"
openssl genpkey -algorithm RSA -out $FQDN.key -pkeyopt rsa_keygen_bits:4096
echo "Génération CSR"
openssl req -new -key $FQDN.key -out $FQDN.csr -subj "/C=FR/ST=PAYS-DE-LOIRE/L=BOPRO/O=homearpa/OU=homearpa/CN=$FQDN"
echo "Signature CSR avec CA"
openssl x509 -req -in $FQDN.csr -CA $CA.crt -CAkey $CA.key -CAcreateserial -out $FQDN.crt -days 3650 -sha256 -extfile $FQDN.ext
echo "Vérification"
openssl verify -CAfile $CA.crt $FQDN.crt

# Tester si dossier existant et y copier le .crt et .key du domaine
[ -d $CADOSSIER ] && { sudo cp $FQDN.crt $CADOSSIER/; sudo cp $FQDN.key $CADOSSIER/; }

# On ajoute les enregistrements au fichier /etc/unbound/unbound.conf.d/local-unbound.conf
#
# local-data: "grist.home.arpa.  86400 IN A <adresse IP>"
# local-data-ptr: "<adresse IP> 86400 grist.home.arpa."
sudo tee -a $CFGUNBOUND << EOF
    local-data: "$FQDN.  86400 IN A $2"
    local-data-ptr: "$2 86400 $FQDN."
EOF
# Redémarrer unbound
sudo systemctl restart unbound

Créer un alias dans .bash_alias

1

alias gencert='$HOME/scripts/gencert.sh'

exemple test.home.arpa

1

gencert test.home.arpa

A l’issue de cette commande des fichiers sont générés

1
2
3
4

├── test.home.arpa.crt
├── test.home.arpa.csr
├── test.home.arpa.ext
├── test.home.arpa.key

Annexe

DNS

Résolveur DNS (/etc/resolv.conf)

Le fichier /etc/resolv.conf est utilisé par le résolveur DNS de la bibliothèque C pour déterminer comment convertir les noms de domaine en adresses IP. En d’autres termes, il indique quelles adresses de serveurs DNS doivent être interrogées lorsqu’une application tente de résoudre un nom de domaine (par exemple, transformer www.example.com en une adresse IP).

Unbound écoute sur l’interface 192.168.0.205, le DNS par défaut est donc la même adresse ip soit 192.168.0.205 (/etc/resolv.conf)

Structure et Syntaxe du Fichier

nameserver : Chaque directive nameserver suivie d’une adresse IP indique un serveur DNS à interroger. Le résolveur tente les requêtes dans l’ordre où les serveurs sont listés. Par défaut, jusqu’à trois serveurs sont utilisés.

1
2

nameserver 1.1.1.1
nameserver 9.9.9.9

Directives

search et domain : * La directive search permet de définir une liste de domaines à ajouter automatiquement aux requêtes incomplètes. * La directive domain est une forme simplifiée qui définit un seul domaine par défaut. * Ces deux directives sont mutuellement exclusives.

1
2

search example.com local
domain example.com

options La directive options permet de spécifier des paramètres supplémentaires : * timeout:n : délai d’attente initial en secondes * attempts:n : nombre de tentatives avant abandon * ndots:n : nombre minimum de points requis dans un nom

1

options timeout:2 attempts:3 ndots:1

Outils et Méthodes de Gestion DNS

  • resolvconf : programme intermédiaire entre différentes sources DNS (DHCP, VPN…), qui évite les conflits entre applications.
  • systemd-resolved : gère automatiquement /etc/resolv.conf via un lien symbolique et fournit un résolveur local.
  • NetworkManager : souvent utilisé avec les outils ci-dessus pour gérer dynamiquement la résolution DNS selon les connexions actives.

Configuration Manuelle

Il est parfois préférable de configurer manuellement /etc/resolv.conf, surtout sur des serveurs. Utilisez un éditeur comme vim ou nano, puis verrouillez le fichier pour éviter qu’il soit écrasé :

1

chattr +i /etc/resolv.conf

Déverrouillez avec :

1

chattr -i /etc/resolv.conf

Problèmes liés au VPN

Problème de résolution sur les domaines locaux home.arpa sur PC1 EndeavourOS si un VPN est actif

Il faut activer le DNS personnalisé dans le paramétrage NordVPN

1

nordvpn set dns 192.168.0.205

Générateur mkcert (Non Utilisé)

Le paquet ca-certificats qui est commun dans chaque distribution Linux est absent de l’installation par défaut de Alpine, vous pouvez installer le paquet ca-certificats avec la commande suivante

1

sudo apk -U add ca-certificates

Les fichiers sont disponibles dans le dossier ~/sharenfs/rnmkcy/.mkcert/

Nous recopions server.crt dans /usr/local/share/ca-certificats/

1
2

sudo mkdir -p /usr/local/share/ca-certificats/
sudo cp ~/sharenfs/rnmkcy/.mkcert/rootCA.pem /usr/local/share/ca-certificats/mkcert.crt

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

1

sudo update-ca-certificates

Cette commande ajoute server.crt au /etc/ssl/certs/ca-certificats.crt.

Nous pouvons vérifier les mises à jour au bas du fichier.

1
2

sudo cp ~/sharenfs/rnmkcy/.mkcert/cwwk.home.arpa+1-key.pem /etc/ssl/private/alp01.home.arpa-key.pem 
sudo cp ~/sharenfs/rnmkcy/.mkcert/cwwk.home.arpa+1.pem  /etc/ssl/private/alp01.home.arpa.pem
Machine, CWWK
dns
Cet article est sous licence CC BY 4.0 par l'auteur.