AD CS : générer un certificat TLS pour un serveur Linux depuis une PKI Windows

Dans la majorité des entreprises, l'infrastructure serveur est hétérogène : des contrôleurs de domaine Windows Server coexistent avec des serveurs Linux hébergeant des applications web, des APIs, des outils DevOps ou des bases de données. Lorsqu'une PKI Active Directory Certificate Services (AD CS) est en place, il serait dommage de ne pas l'utiliser pour signer les certificats TLS des serveurs Linux. Cela présente de nombreux avantages : les navigateurs des postes membres du domaine Windows font immédiatement confiance aux certificats signés par la CA interne, la gestion est centralisée, les coûts de certificats publics sont réduits pour les usages purement internes, et la cohérence de la politique de sécurité PKI est maintenue sur l'ensemble du parc. Ce guide vous explique en détail comment générer une demande de signature de certificat (CSR) sur Linux avec OpenSSL en spécifiant les Subject Alternative Names requis, comment soumettre cette requête à votre CA AD CS Windows, comment récupérer et formater le certificat signé, et comment le déployer sur Apache ou Nginx. Vous découvrirez également comment automatiser le renouvellement via un script cron, et comment diagnostiquer les erreurs les plus fréquentes comme l'absence de SAN ou les problèmes de chaîne de confiance.

Pourquoi signer les certificats Linux avec la PKI Windows AD CS

La question se pose souvent : pourquoi ne pas utiliser des certificats auto-signés ou Let's Encrypt pour les serveurs Linux internes ? La réponse tient en trois points.

Premièrement, les certificats auto-signés génèrent des avertissements de sécurité dans tous les navigateurs et les clients HTTP. Les utilisateurs apprennent à cliquer sur "Continuer malgré le risque", ce qui les rend moins vigilants face à de véritables attaques. Les outils d'intégration CI/CD, les clients API et les agents de monitoring rencontrent également des erreurs SSL difficiles à gérer de façon sécurisée.

Deuxièmement, Let's Encrypt est inadapté aux usages purement internes. Il nécessite un accès Internet pour valider les domaines (challenge HTTP-01 ou DNS-01) et les certificats ont une durée de vie de 90 jours, exigeant un renouvellement automatique parfaitement fiable. Pour des noms de domaine internes (.local, .intranet, .corp) non résolubles depuis Internet, Let's Encrypt n'est tout simplement pas utilisable.

Troisièmement, votre PKI AD CS est déjà distribuée à tous les postes Windows du domaine via GPO. Un certificat signé par votre CA interne est immédiatement reconnu par tous les navigateurs, clients Outlook, et applications internes sur ces postes. Cela offre une expérience utilisateur transparente et une sécurité réelle sans compromis.

Pour les environnements hybrides avec des postes Linux, des smartphones ou des clients extérieurs, la PKI interne peut être complétée par des certificats publics pour les interfaces exposées. La PKI interne AD CS reste alors le standard pour les communications intra-réseau.

Générer un CSR sur Linux (openssl req, paramètres SAN, fichier .conf)

La génération d'un Certificate Signing Request (CSR) sur Linux se fait avec OpenSSL. L'étape critique est d'inclure les Subject Alternative Names (SAN) — sans SAN, les navigateurs modernes rejettent le certificat même si le CN est correct. Depuis Chrome 58 (2017), le CN est ignoré au profit des SAN.

Créez d'abord un fichier de configuration OpenSSL qui inclut les extensions SAN :

# /etc/ssl/ayinedjimi/intranet.conf
[req]
default_bits        = 2048
default_md          = sha256
distinguished_name  = req_distinguished_name
req_extensions      = v3_req
prompt              = no

[req_distinguished_name]
C  = FR
ST = Ile-de-France
L  = Paris
O  = AyiNedjimi Consultants
OU = IT
CN = intranet.ayinedjimi.fr

[v3_req]
keyUsage         = keyEncipherment, dataEncipherment, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName   = @alt_names

[alt_names]
DNS.1 = intranet.ayinedjimi.fr
DNS.2 = intranet
DNS.3 = intranet.ayinedjimi.local
IP.1  = 192.168.10.50

Générez la clé privée et le CSR :

# Créer le répertoire de travail
mkdir -p /etc/ssl/ayinedjimi
chmod 700 /etc/ssl/ayinedjimi

# Générer la clé privée RSA 2048 bits
openssl genrsa -out /etc/ssl/ayinedjimi/intranet.key 2048
chmod 600 /etc/ssl/ayinedjimi/intranet.key

# Générer le CSR avec le fichier de configuration
openssl req -new \
  -key /etc/ssl/ayinedjimi/intranet.key \
  -out /etc/ssl/ayinedjimi/intranet.csr \
  -config /etc/ssl/ayinedjimi/intranet.conf

# Vérifier le contenu du CSR
openssl req -text -noout -in /etc/ssl/ayinedjimi/intranet.csr | grep -A5 "Subject Alternative"

La vérification doit afficher vos DNS et IP configurés. Si la section "Requested Extensions" ne contient pas les SAN, le problème vient du fichier .conf — vérifiez les sections et la syntaxe.

Pour une clé RSA 4096 bits (recommandée pour une durée de vie > 2 ans ou des données très sensibles), remplacez simplement 2048 par 4096. Pour une clé ECDSA P-256 (plus moderne et plus rapide) :

openssl ecparam -name prime256v1 -genkey -noout -out /etc/ssl/ayinedjimi/intranet-ec.key
openssl req -new -key /etc/ssl/ayinedjimi/intranet-ec.key -out /etc/ssl/ayinedjimi/intranet-ec.csr -config /etc/ssl/ayinedjimi/intranet.conf

Soumettre le CSR à l'AD CS Windows (certreq.exe, portail Web CA)

Une fois le CSR généré sur Linux, vous devez le transférer vers un environnement Windows pour le soumettre à votre CA AD CS. Deux méthodes sont disponibles.

Méthode 1 : Via le portail Web Enrollment (certreq.asp)

Ouvrez un navigateur sur un poste Windows membre du domaine et accédez à http://ca-emettrice.ayinedjimi.fr/certsrv. Authentifiez-vous avec vos credentials domaine, puis :

1. Cliquez "Request a certificate"
2. Cliquez "Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file"
3. Collez le contenu du fichier intranet.csr (y compris les lignes -----BEGIN et END-----)
4. Sélectionnez le modèle "AyiNedjimi Web Server v1"
5. Cliquez Submit
6. Si l'approbation automatique est configurée : téléchargez le certificat en format Base 64 encoded (.cer)

Méthode 2 : Via certreq.exe depuis un poste Windows

Copiez intranet.csr sur un poste Windows et soumettez depuis PowerShell ou cmd :

certreq -submit `
  -config "ca-emettrice.ayinedjimi.fr\AyiNedjimi Issuing CA 01" `
  -attrib "CertificateTemplate:AyiNedjimiWebServerv1" `
  C:\temp\intranet.csr `
  C:\temp\intranet.cer

Si vous obtenez l'erreur "The certificate template could not be loaded", vérifiez que le nom du template correspond exactement au nom interne (sans espaces, visible dans les propriétés du modèle, onglet General, champ "Template name").

Pour les environnements avec validation manuelle (modèle configuré en "Pending"), un administrateur CA doit approuver la requête dans la console Certification Authority avant que le certificat ne soit disponible au téléchargement.

Récupérer et formater le certificat signé (PEM vs DER vs PFX)

Le certificat téléchargé depuis l'interface Web Enrollment est généralement au format DER (.cer) ou Base64/PEM (.cer ou .crt). Linux requiert le format PEM. Voici les conversions nécessaires :

# Convertir DER en PEM
openssl x509 -inform DER -in intranet.cer -out intranet.crt

# Vérifier que c'est bien du PEM
head -1 intranet.crt  # Doit afficher: -----BEGIN CERTIFICATE-----

# Vérifier les détails du certificat
openssl x509 -text -noout -in intranet.crt | grep -E "Subject:|Issuer:|Not After|DNS:"

Si vous avez téléchargé la "certificate chain" (recommandé), vous obtenez un fichier contenant le certificat serveur + le certificat de la CA intermédiaire. Séparez-les pour Apache/Nginx :

# Séparer les certificats dans la chaîne
csplit -z -f cert- intranet-chain.crt '/-----BEGIN CERTIFICATE-----/' '{*}'

# cert-00 = certificat serveur, cert-01 = certificat CA (à adapter selon l'ordre)
mv cert-00 intranet.crt
mv cert-01 ca-chain.crt

Pour récupérer également le certificat Root CA (nécessaire pour constituer la chaîne complète sur Linux) :

# Télécharger depuis l'URL AIA du certificat CA
openssl x509 -in intranet.crt -noout -text | grep "CA Issuers"
# Récupérer l'URL de la Root CA
wget -q "http://pki.ayinedjimi.fr/pki/AyiNedjimiRootCA.crt" -O rootca.crt
# Convertir si nécessaire
openssl x509 -inform DER -in rootca.crt -out rootca.pem

Constituez la chaîne complète pour les serveurs web :

cat intranet.crt ca-chain.crt rootca.pem > intranet-fullchain.crt

Déployer le certificat sur Apache (ssl.conf, Virtual Host)

Apache nécessite au minimum la clé privée, le certificat serveur, et idéalement la chaîne de CA intermédiaires. Sur Debian/Ubuntu :

# Copier les fichiers
install -m 644 /etc/ssl/ayinedjimi/intranet.crt /etc/ssl/certs/
install -m 644 /etc/ssl/ayinedjimi/ca-chain.crt /etc/ssl/certs/
install -m 600 /etc/ssl/ayinedjimi/intranet.key /etc/ssl/private/

# Activer le module SSL
a2enmod ssl
a2enmod headers

Créez ou modifiez le VirtualHost HTTPS :

<VirtualHost *:443>
    ServerName intranet.ayinedjimi.fr
    ServerAlias intranet

    DocumentRoot /var/www/intranet

    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/intranet.crt
    SSLCertificateKeyFile   /etc/ssl/private/intranet.key
    SSLCertificateChainFile /etc/ssl/certs/ca-chain.crt

    # Sécurisation TLS
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
    SSLHonorCipherOrder     off
    SSLSessionTickets       off

    # HSTS (après validation)
    Header always set Strict-Transport-Security "max-age=63072000"

    <Directory /var/www/intranet>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

# Redirection HTTP vers HTTPS
<VirtualHost *:80>
    ServerName intranet.ayinedjimi.fr
    Redirect permanent / https://intranet.ayinedjimi.fr/
</VirtualHost>

# Tester la configuration
apache2ctl configtest

# Recharger Apache
systemctl reload apache2

# Vérifier le certificat depuis la ligne de commande
openssl s_client -connect intranet.ayinedjimi.fr:443 -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer

Déployer le certificat sur Nginx (server block SSL)

Nginx requiert une configuration légèrement différente, notamment pour la chaîne de certificats qui doit être concaténée dans un seul fichier :

# Copier les fichiers
install -m 644 /etc/ssl/ayinedjimi/intranet-fullchain.crt /etc/ssl/certs/
install -m 600 /etc/ssl/ayinedjimi/intranet.key /etc/ssl/private/

Configuration Nginx (/etc/nginx/sites-available/intranet.conf) :

server {
    listen 443 ssl http2;
    server_name intranet.ayinedjimi.fr intranet;

    ssl_certificate     /etc/ssl/certs/intranet-fullchain.crt;
    ssl_certificate_key /etc/ssl/private/intranet.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000" always;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    location / {
        root /var/www/intranet;
        index index.html;
    }
}

server {
    listen 80;
    server_name intranet.ayinedjimi.fr;
    return 301 https://$host$request_uri;
}

# Tester et recharger Nginx
nginx -t && systemctl reload nginx

Configurer le renouvellement automatique (script + cron)

Les certificats internes ont généralement une durée de vie de 1 à 2 ans. Pour éviter les expiration silencieuses, automatisez le processus de renouvellement.

Créez le script de renouvellement /opt/pki/renew-cert.sh :

#!/bin/bash
# Renouvellement automatique certificat AD CS pour Linux
# Prérequis : certreq disponible via Wine ou serveur Windows intermédiaire

CERT_DIR="/etc/ssl/ayinedjimi"
CERT_NAME="intranet"
CA_SERVER="ca-emettrice.ayinedjimi.fr"
CA_NAME="AyiNedjimi Issuing CA 01"
TEMPLATE="AyiNedjimiWebServerv1"
DAYS_BEFORE=30

# Vérifier la date d'expiration
EXPIRY=$(openssl x509 -enddate -noout -in "${CERT_DIR}/${CERT_NAME}.crt" | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "${EXPIRY}" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

echo "$(date): Certificat expire dans ${DAYS_LEFT} jours"

if [ "${DAYS_LEFT}" -gt "${DAYS_BEFORE}" ]; then
    echo "Renouvellement non nécessaire"
    exit 0
fi

echo "Début du renouvellement..."

# Générer nouveau CSR
openssl req -new \
  -key "${CERT_DIR}/${CERT_NAME}.key" \
  -out "/tmp/${CERT_NAME}-renew.csr" \
  -config "${CERT_DIR}/${CERT_NAME}.conf"

# Soumettre via CURL au portail Web Enrollment
# (Adapté selon votre méthode de soumission)
# Alternative: script PowerShell sur serveur Windows dédié

# Après récupération du nouveau cert
# openssl x509 -inform DER -in /tmp/${CERT_NAME}-new.cer -out "${CERT_DIR}/${CERT_NAME}.crt"
# systemctl reload apache2 nginx

echo "$(date): Renouvellement terminé" >> /var/log/pki-renew.log

chmod +x /opt/pki/renew-cert.sh

# Ajouter au cron (vérification hebdomadaire)
echo "0 6 * * 1 root /opt/pki/renew-cert.sh >> /var/log/pki-renew.log 2>&1" \
  > /etc/cron.d/pki-renew

Pour une intégration plus robuste, utilisez un serveur Windows intermédiaire qui reçoit les CSR Linux (via scp ou une API interne), les soumet à la CA AD CS, et retourne les certificats signés. Cette approche découple Linux de la nécessité d'avoir certutil ou certreq installé.

Dépannage — erreurs courantes (SAN manquant, chaîne de confiance)

Voici les erreurs les plus fréquentes lors du déploiement de certificats AD CS sur Linux :

ERR_CERT_COMMON_NAME_INVALID ou NET::ERR_CERT_INVALID : Le SAN est absent ou ne correspond pas au nom d'hôte. Vérifiez avec openssl x509 -text -noout -in cert.crt | grep DNS. Si vide, le CSR a été généré sans le fichier .conf. Recommencez avec la configuration SAN explicite.

UNABLE_TO_VERIFY_LEAF_SIGNATURE / unable to get local issuer certificate : La chaîne de confiance est incomplète. Le serveur web ne présente pas le certificat de la CA intermédiaire. Sur Nginx, vérifiez que le fichier fullchain.crt contient bien les deux certificats (serveur + CA intermédiaire) dans le bon ordre. Sur Apache, vérifiez la directive SSLCertificateChainFile.

Certificat non reconnu par les postes Windows du domaine : Le certificat Root CA n'est pas encore distribué via GPO sur les postes concernés, ou la GPO n'a pas encore été appliquée. Forcez gpupdate /force sur les postes clients. Vérifiez dans certmgr.msc que le Root CA apparaît dans "Trusted Root Certification Authorities".

Le modèle de certificat ne s'affiche pas dans la liste (Web Enrollment) : L'utilisateur ou le serveur demandeur n'a pas la permission "Enroll" sur le modèle. Vérifiez les permissions dans certtmpl.msc (onglet Security du modèle). Pour les serveurs Linux, vous devrez utiliser un compte de service Windows avec les bonnes permissions pour soumettre les requêtes.

Erreur "The request contains no certificate template information" : Spécifiez le modèle via l'attribut RequestAttributes dans votre requête certreq, ou sélectionnez-le manuellement dans le portail Web Enrollment.

Pour approfondir la configuration PKI côté Windows, consultez notre guide complet sur le déploiement d'une PKI AD CS avec Root CA offline.

Valider que le certificat est reconnu par les navigateurs du domaine

La validation finale est cruciale avant de mettre en production. Effectuez ces vérifications depuis différents types de clients :

Test depuis Linux avec OpenSSL :

# Test de connexion SSL complet
openssl s_client -connect intranet.ayinedjimi.fr:443 -CAfile /etc/ssl/certs/ca-bundle.crt

# Vérifier la chaîne de certificats
openssl verify -CAfile rootca.pem -untrusted ca-chain.crt intranet.crt

# Vérifier la date d'expiration
echo | openssl s_client -connect intranet.ayinedjimi.fr:443 2>/dev/null \
  | openssl x509 -noout -dates

Test depuis Windows (PowerShell) :

# Vérifier la chaîne de confiance
$cert = [System.Net.ServicePointManager]::ServerCertificateValidationCallback
$req = [System.Net.WebRequest]::Create("https://intranet.ayinedjimi.fr")
$resp = $req.GetResponse()
Write-Host "SSL OK: $($resp.StatusCode)"

# Via certutil
certutil -verify -urlfetch C:\temp\intranet.crt

Test navigateur : Ouvrez Chrome, Firefox ou Edge sur un poste du domaine et naviguez vers https://intranet.ayinedjimi.fr. La barre d'adresse doit afficher un cadenas vert sans avertissement. Cliquez sur le cadenas pour inspecter les détails du certificat et vérifier que l'émetteur correspond à votre CA interne.

Pour les postes Linux hors domaine AD, ajoutez manuellement le certificat Root CA dans le magasin de confiance du système :

# Ubuntu/Debian
cp rootca.pem /usr/local/share/ca-certificates/ayinedjimi-root.crt
update-ca-certificates

# RHEL/CentOS/Fedora
cp rootca.pem /etc/pki/ca-trust/source/anchors/ayinedjimi-root.crt
update-ca-trust

Référez-vous également à la documentation officielle Microsoft AD CS pour les détails de configuration avancée et aux guides Apache SSL/TLS pour les options de configuration TLS avancées.

Il est également judicieux de surveiller l'état de vos certificats en production à l'aide d'outils de monitoring comme Prometheus avec l'exporteur ssl_exporter, ou Zabbix avec le template de surveillance des certificats. Ces outils peuvent déclencher des alertes automatiques plusieurs semaines avant l'expiration d'un certificat, offrant une visibilité centralisée sur l'ensemble du parc de certificats — qu'ils soient issus d'une PKI interne AD CS ou de CAs publiques. Une alerte à J-60, J-30 et J-7 est une bonne pratique pour éviter toute interruption de service liée à un certificat expiré.

Dans les environnements DevOps modernes, l'intégration de la gestion des certificats dans les pipelines CI/CD est de plus en plus courante. Des outils comme HashiCorp Vault peuvent agir comme intermédiaire entre vos serveurs Linux et votre PKI AD CS, centralisant la génération de CSR, la récupération de certificats et leur distribution sécurisée aux applications via des API. Cette approche infrastructure-as-code de la gestion PKI réduit les interventions manuelles et assure la traçabilité complète de chaque opération liée aux certificats.

Enfin, tenez un inventaire précis de tous vos certificats déployés : quel serveur, quel service, quelle date d'expiration, quel modèle AD CS utilisé. Une simple feuille de calcul peut suffire pour un petit environnement, mais pour les parcs de plus de 50 serveurs, des solutions dédiées de Certificate Lifecycle Management (CLM) comme Keyfactor, Venafi ou DigiCert Certificate Manager offrent des fonctionnalités d'inventaire, d'alertes et de renouvellement automatisé qui valent largement leur investissement en termes de réduction des incidents liés aux certificats.

FAQ — Certificats AD CS sur Linux

Est-il possible de soumettre un CSR Linux directement à la CA AD CS sans passer par un poste Windows ?

Oui, avec quelques approches alternatives. La première est d'utiliser le portail Web Enrollment (certsrv) depuis un navigateur Linux — le portail est accessible depuis n'importe quel navigateur si l'authentification NTLM ou Kerberos est configurée. La seconde est d'utiliser des outils comme certmonger sur Linux, qui supporte l'émission de certificats via le protocole MS-WCCE (Windows Client Certificate Enrollment Protocol) utilisé par AD CS. La troisième est de déployer un script Python avec la bibliothèque impacket qui supporte les opérations AD CS. Dans tous les cas, les credentials d'un compte AD autorisé à demander des certificats sur le modèle concerné sont nécessaires.

Quelle durée de validité recommandez-vous pour les certificats serveurs internes ?

La recommandation actuelle est de 1 à 2 ans maximum pour les certificats serveurs, même en PKI interne. Le standard de l'industrie tend vers 1 an (398 jours, imposé par Apple/Google pour les certificats publics). En PKI interne, vous pouvez aller jusqu'à 2 ans pour réduire la charge opérationnelle, mais pas au-delà. Des certificats de longue durée (5 ans ou plus) étaient courants par le passé mais représentent un risque : si la clé privée est compromise, le certificat reste "valide" longtemps avant d'expirer naturellement. Avec un processus de renouvellement automatisé, 1 an est le standard recommandé.

Comment faire si mon serveur Linux doit être accessible à la fois en interne et depuis Internet ?

Pour un serveur exposé à la fois en interne et sur Internet, utilisez deux approches complémentaires. Pour l'accès Internet, utilisez un certificat public Let's Encrypt ou d'une CA commerciale sur votre reverse proxy ou load balancer. Pour l'accès interne direct (contournement du proxy, API internes), déployez également le certificat AD CS. Certains déploiements utilisent le SAN pour inclure à la fois le FQDN public et le nom interne dans un seul certificat, mais cela nécessite que la CA interne soit reconnue par les clients Internet, ce qui n'est généralement pas le cas. La séparation propre (cert public pour l'exposition externe, cert interne pour les communications intra-réseau) est la pratique recommandée.

Mon certificat AD CS affiche "Untrusted" sur Firefox même si Edge l'accepte — pourquoi ?

Firefox utilise son propre magasin de certificats (NSS) et n'utilise pas le magasin Windows par défaut. Pour que Firefox fasse confiance à votre CA AD CS, vous devez soit importer manuellement le certificat Root CA dans Firefox (Paramètres → Confidentialité et sécurité → Afficher les certificats → Autorités → Importer), soit déployer la configuration Firefox via GPO en utilisant les stratégies Firefox Enterprise (certificates.json ou group_policy). La stratégie enterprise permet d'automatiser cette opération sur tous les postes Windows avec Firefox installé.

Puis-je utiliser des certificats ECDSA (P-256) avec la PKI AD CS Windows ?

Oui, AD CS supporte les certificats ECDSA depuis Windows Server 2012 R2. Le provider "Microsoft Software Key Storage Provider" supporte les courbes P-256, P-384 et P-521. Pour les modèles de certificats, assurez-vous de sélectionner un algorithme compatible dans les paramètres cryptographiques. La commande de génération CSR sur Linux utilise openssl ecparam -name prime256v1 pour P-256. Les certificats ECDSA P-256 offrent une sécurité équivalente à RSA 3072 bits avec des performances bien supérieures, ce qui est particulièrement bénéfique pour des serveurs à fort trafic.