• Autorité de Certification (CA) : Émet les certificats et garantit l'association entre une identité et une clé publique
• Autorité d'Enregistrement (RA) : Vérifie l'identité des demandeurs de certificats
• Référentiel de certificats : Stocke et distribue les certificats
• Système de révocation : Permet d'invalider les certificats compromis ou obsolètes (CRL, OCSP)
• Applications utilisatrices : Systèmes qui vérifient et utilisent les certificats

• Établissement d'identité : Vérifier rigoureusement qui demande un certificat
• Émission de certificats : Créer des certificats avec les informations validées
• Distribution : Rendre les certificats accessibles aux utilisateurs
• Révocation : Permettre l'invalidation de certificats compromis
• Renouvellement : Gérer le cycle de vie des certificats
• Validation : Vérifier l'authenticité et la validité des certificats

Caractéristiques :

• Structure arborescente avec une autorité racine
• Chaînes de certification claires
• Point central de confiance

Avantages : Simple à comprendre, facile à gérer

Inconvénients : Vulnérable à la compromission de la racine

Caractéristiques :

• Les CAs se certifient mutuellement
• Plusieurs chemins de certification possibles
• Relations de confiance plus complexes

Avantages : Plus robuste, pas de point unique de défaillance

Inconvénients : Plus difficile à gérer et à comprendre

Caractéristiques :

• Décentralisé, sans autorités centrales
• Les utilisateurs se certifient mutuellement
• Niveau de confiance basé sur le réseau social

Avantages : Totalement décentralisé, peu coûteux

Inconvénients : Difficile à déployer à grande échelle

• Version : Version du format PKCS#10 (généralement 0)
• Nom du sujet : DN de l'entité demandant le certificat
• Clé publique : La clé publique à certifier
• Attributs : Extensions demandées pour le certificat
• Signature : Signature par la clé privée correspondante

openssl req -new -newkey rsa:2048 -nodes \
    -keyout private.key -out request.csr

$ openssl req -text -noout -in request.csr
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=FR, ST=Île-de-France, L=Paris, 
                 O=Example Corporation, 
                 OU=IT Department, 
                 CN=www.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b9:41:e3:36:49:5e:a3:...
                Exponent: 65537 (0x10001)
        Attributes:
            challengePassword:     (hidden)
            unstructuredName:      Example Corp Server
    Signature Algorithm: sha256WithRSAEncryption
         5f:4a:8a:f2:38:40:1c:...

Une CRL est une liste signée par la CA contenant les numéros de série des certificats révoqués et non expirés.

Caractéristiques :

• Publication périodique (quotidienne, hebdomadaire)
• Mise à jour incrémentale possible (delta CRL)
• Distribuée via HTTP, LDAP ou autres protocoles
• Contient la date de révocation et motif optionnel

Inconvénients :

• Taille potentiellement importante
• Latence entre révocation et publication
• Charge réseau significative

OCSP permet de vérifier en temps réel le statut d'un certificat spécifique auprès d'un répondeur.

Fonctionnement :

• Requête pour un certificat spécifique
• Réponses signées : "good", "revoked" ou "unknown"
• Plus efficace que les CRL pour les vérifications individuelles

Améliorations récentes :

• OCSP Stapling : Le serveur attache périodiquement une réponse OCSP signée à sa communication TLS
• Must-Staple : Extension de certificat indiquant que le stapling est obligatoire
• CertificateTransparency (CT) : Logs publics vérifiables des certificats émis

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /path/to/server-chain.crt;
    ssl_certificate_key /path/to/server.key;
    
    # Configurations recommandées
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...';
    ssl_prefer_server_ciphers on;
    
    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /path/to/ca-chain.crt;
    
    # Autres directives...
}

// Charger le keystore contenant le certificat client
System.setProperty("javax.net.ssl.keyStore", 
    "/path/to/client.keystore");
System.setProperty("javax.net.ssl.keyStorePassword", 
    "password");

// Charger le truststore contenant les CA de confiance
System.setProperty("javax.net.ssl.trustStore", 
    "/path/to/truststore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", 
    "password");

// Convertir PEM en JKS
// keytool -import -file ca.crt -alias ca 
//   -keystore truststore.jks

// Créer une connexion HTTPS
URL url = new URL("https://example.com");
HttpsURLConnection conn = 
    (HttpsURLConnection) url.openConnection();
// Configurer la connexion...
conn.connect();

# Vérifier une connexion HTTPS
openssl s_client -connect example.com:443 \
  -servername example.com -CAfile ca-chain.crt

# Vérifier un certificat local
openssl verify -CAfile ca-chain.crt server.crt

# Vérifier l'état de révocation
openssl ocsp -issuer intermediate-ca.crt \
  -cert server.crt \
  -url http://ocsp.example.com \
  -CAfile ca-chain.crt

# Extraire des informations d'un certificat
openssl x509 -in server.crt -text -noout

# Vérifier le keyUsage et les extensions
openssl x509 -in server.crt -purpose -noout

1. Le client se connecte au serveur et demande une connexion sécurisée
2. Le serveur envoie son certificat et demande un certificat au client
3. Le client vérifie le certificat du serveur
4. Le client envoie son propre certificat au serveur
5. Le serveur vérifie le certificat du client
6. Les deux parties établissent une session chiffrée

Cas d'usage typiques :

• Communication entre microservices dans un environnement zero-trust
• API sécurisées pour partenaires commerciaux
• Authentification d'appareils IoT
• VPN basés sur certificats
• Services financiers et systèmes critiques

Avantages :

• Authentification forte des deux parties
• Élimination des mots de passe
• Granularité fine du contrôle d'accès
• Révocation possible des accès compromis
• Audit et traçabilité améliorés

server {
    listen 443 ssl;
    
    ssl_certificate /path/to/server.crt;
    ssl_certificate_key /path/to/server.key;
    ssl_client_certificate /path/to/ca.crt;
    ssl_verify_client on;
    
    # ...
}

1. Obtention d'un certificat : Acquérir un certificat de signature de code auprès d'une CA reconnue
2. Compilation du code : Développer et compiler l'application
3. Calcul du hachage : Générer une empreinte cryptographique du code
4. Signature : Signer l'empreinte avec la clé privée associée au certificat
5. Intégration : Inclure la signature et le certificat avec le logiciel

Exemple avec signtool (Windows) :

signtool sign /f certificate.pfx /p password 
    /tr http://timestamp.digicert.com /td sha256 
    /fd sha256 application.exe

Exemple avec jarsigner (Java) :

jarsigner -keystore keystore.jks -storepass password 
    -keypass keypass application.jar alias

Processus de vérification :

1. L'OS ou l'environnement d'exécution extrait le certificat du logiciel
2. Vérification de la chaîne de certification jusqu'à une CA de confiance
3. Vérification que le certificat est valide et non révoqué
4. Vérification de la signature en utilisant la clé publique du certificat
5. Affichage d'une notification à l'utilisateur ou autorisation silencieuse

Avantages :

• Garantie de l'origine du logiciel
• Détection de toute modification après la signature
• Réduction des avertissements de sécurité
• Établissement de la réputation du développeur
• Prévention de certaines attaques de type "supply chain"

Fragilités structurelles :

• Confiance excessive accordée à des centaines de CAs
• Systèmes de révocation inefficaces ou ignorés
• Complexité du système pour les utilisateurs finaux
• Vulnérabilités dues à des erreurs d'implémentation

Menaces émergentes :

• Compromission d'autorités de certification
• Attaques quantiques contre les algorithmes asymétriques
• Augmentation des attaques "man-in-the-middle" sophistiquées
• Prolifération d'appareils IoT avec contraintes de ressources

Évolutions technologiques :

• Certificats résistants aux attaques quantiques : Migration vers des algorithmes post-quantiques
• Blockchain et technologies distribuées : Exploration de PKI sans autorité centrale
• Automatisation complète : Adoption croissante d'ACME et de solutions similaires
• Durée de vie réduite : Tendance vers des certificats à plus courte durée (90 jours ou moins)

Nouveaux modèles :

• Web of Trust modernes : Nouvelles approches de la confiance décentralisée
• Identity-based Encryption (IBE) : Utilisation d'identifiants comme clés publiques
• Certificate-less PKI : Systèmes éliminant le besoin de certificats traditionnels
• Identités auto-souveraines : Contrôle complet des utilisateurs sur leurs identités numériques