RSA vs ECDSA : quel certificat TLS choisir pour Parallels RAS ?

Le certificat TLS de votre Secure Gateway n’est pas qu’une formalité pour le cadenas vert. C’est un composant actif sollicité à chaque ouverture de session. Sur un déploiement de plusieurs milliers d’utilisateurs, le choix de l’algorithme a un impact mesurable sur les performances de vos gateways.

Ce benchmark couvre les trois candidats réalistes en 2026 : RSA 4096, ECDSA P-256 et ECDSA P-384. Les tests ont été réalisés sur un environnement Parallels RAS 21 avec une PKI Microsoft ADCS, depuis un client Linux en LAN.

Pourquoi le certificat impacte les performances

Quand un utilisateur ouvre sa session Parallels RAS, la première étape est un handshake TLS entre son client et la Secure Gateway. C’est là que le certificat entre en jeu : il sert à authentifier le serveur et à établir le canal chiffré. Une fois la session ouverte, tout le trafic RAS passe en chiffrement symétrique AES-256-GCM — et là, le type de certificat n’a strictement plus aucune influence.

Sur quelques dizaines d’utilisateurs, la différence est imperceptible. Mais sur un déploiement de 3 500 à 6 000 utilisateurs qui ouvrent tous leur session entre 8h et 9h, multiplier le coût du handshake par le nombre de connexions simultanées se traduit concrètement par une charge CPU mesurable sur vos Secure Gateways.

Les familles de certificats TLS en 2026

RSA — L’ancien standard. Clés longues (2048, 4096 bits), calculs asymétriques coûteux côté serveur. Compatibilité maximale avec tous les clients, y compris les plus anciens. À considérer comme un choix héritage en 2026.

ECDSA (courbes NIST) — Basé sur les courbes elliptiques. P-256 offre 128 bits de sécurité symétrique — impossible à casser avec les moyens actuels. C’est le choix recommandé pour Parallels RAS.

EdDSA / Ed25519 — Courbe de Bernstein, plus moderne qu’ECDSA. Très rapide. La compatibilité côté client Windows est à vérifier selon votre version de RAS avant tout déploiement.

Post-quantique (ML-KEM, ML-DSA) — Standardisés par le NIST en 2024. Pas encore utilisables en production RAS. Horizon réaliste : 2027-2028.

Setup du benchmark

Trois listeners Parallels RAS dédiés sur trois FQDN distincts pointant sur la même IP. Certificats signés par une PKI Microsoft ADCS (Windows Server 2025). Mesures depuis un client Kali Linux en LAN avec curl (5 runs), Apache Benchmark ab (100 requêtes, 20 connexions simultanées) et Wireshark/tshark.

Résultats — Temps de handshake (curl)

Moyenne sur 5 runs en LAN depuis un client Linux :

Résultats — Charge sous 20 connexions simultanées (ab)

P-256 traite 2x plus de connexions par seconde que RSA 4096 (199 vs 97 req/s). Le temps maximum RSA 4096 monte à 604ms contre 165ms pour P-256 — c’est exactement ce qui se traduit par des lenteurs visibles lors d’un pic matinal.

Résultats — Taille des échanges (Wireshark)

Tout le delta vient du Server Hello : la clé publique RSA 4096 pèse 512 bytes contre environ 65 bytes pour P-256, ce qui gonfle la réponse serveur de près d’un kilobyte.

Pourquoi pas P-384 par défaut ?

P-256 offre 128 bits de sécurité symétrique équivalente — impossible à casser avec les moyens actuels. P-384 monte à 192 bits : du surniveau pour un service RAS. Le NIST considère P-256 suffisant pour la majorité des usages au-delà de 2030. P-384 se justifie uniquement si une exigence réglementaire l’impose explicitement (classification gouvernementale, RGS niveau 3+).

P-384, c’est comme mettre une porte blindée 5 points sur un bunker qui a déjà une porte blindée 3 points — pendant que les murs sont en parpaing. Le vrai gain sécurité est ailleurs : MFA, segmentation réseau, durcissement des RDSH.

Concernant l’argument quantique : P-384 ne protège pas mieux contre un ordinateur quantique que P-256. La résistance quantique vient d’algorithmes post-quantiques comme ML-KEM, pas de la taille de la courbe ECC.

Recommandation

ECDSA P-256 est le choix de production pour Parallels RAS en 2026. Handshake 2x plus rapide que RSA 4096, débit sous charge doublé (199 vs 97 req/s), taille d’échange réduite de 18%. Compatible avec tous les clients modernes (Windows 10+, macOS, Linux, iOS, Android).

• P-384 si votre politique sécurité l’exige explicitement (RGS, classification).
• RSA 4096 uniquement pour des clients legacy ne supportant pas ECDSA — cas très rare en 2026.

Post-quantique — état des lieux

Le NIST a standardisé ML-KEM et ML-DSA en 2024. Horizon réaliste pour du post-quantique en production RAS : 2027-2028 au plus tôt. En attendant, P-256 est le bon choix — et quand viendra la migration, P-256 ne sera pas plus difficile à remplacer que RSA 4096.

Créer les templates ADCS — procédure complète

ADCS a été conçu à l’époque RSA. Le support ECDSA a été ajouté après coup et l’interface graphique ne permet pas tout configurer via ADSI seul. Points importants : les templates ECDSA nécessitent une étape manuelle dans certtmpl.msc après le script, et les deux templates ECDSA doivent être publiés séparément avec un délai de 5 secondes.

Étape 1 — Création des templates (PowerShell sur le DC)

$configNC = ([ADSI]"LDAP://RootDSE").configurationNamingContext
$container = [ADSI]"LDAP://CN=Certificate Templates,CN=Public Key Services,CN=Services,$configNC"

$validity = [byte[]](0x00,0x40,0x39,0x87,0x2e,0x23,0xfe,0xff)
$overlap  = [byte[]](0x00,0x80,0xa6,0x0a,0xff,0xde,0xff,0xff)

foreach ($name in @("RAS-RSA-4096", "RAS-ECDSA-P256", "RAS-ECDSA-P384")) {
    $existing = $container.Children | Where-Object { $_.cn -eq $name }
    if ($existing) {
        $container.Delete("pKICertificateTemplate", "CN=$name")
        Write-Host "Supprime : $name" -ForegroundColor Yellow
    }
}

# RSA 4096
$t = $container.Create("pKICertificateTemplate", "CN=RAS-RSA-4096")
$t.Put("displayName", "RAS-RSA-4096")
$t.Put("flags", 131680)
$t.Put("revision", "100")
$t.Put("pKIDefaultKeySpec", 1)
$t.Put("msPKI-Minimal-Key-Size", 4096)
$t.Put("msPKI-Private-Key-Flag", 101056528)
$t.Put("msPKI-Template-Schema-Version", 2)
$t.Put("msPKI-Template-Minor-Revision", 2)
$t.Put("msPKI-Certificate-Name-Flag", 1)
$t.Put("msPKI-Enrollment-Flag", 0)
$t.Put("msPKI-RA-Signature", 0)
$t.Put("msPKI-MaxIssuingDepth", 0)
$t.Put("msPKI-Cert-Template-OID", "1.3.6.1.4.1.311.21.8.$(Get-Random -Max 9999999).$(Get-Random -Max 9999999)")
$t.Put("pKIDefaultCSPs", @("1,Microsoft RSA SChannel Cryptographic Provider"))
$t.Put("pKIExpirationPeriod", $validity)
$t.Put("pKIOverlapPeriod", $overlap)
$t.Put("pKIExtendedKeyUsage", @("1.3.6.1.5.5.7.3.1"))
$t.Put("pKIKeyUsage", [byte[]](0x03, 0x02, 0x05, 0xa0))
$t.SetInfo()
Write-Host "Cree : RAS-RSA-4096" -ForegroundColor Green

# ECDSA P-256
$t = $container.Create("pKICertificateTemplate", "CN=RAS-ECDSA-P256")
$t.Put("displayName", "RAS-ECDSA-P256")
$t.Put("flags", 131680)
$t.Put("revision", "100")
$t.Put("pKIDefaultKeySpec", 2)
$t.Put("msPKI-Minimal-Key-Size", 256)
$t.Put("msPKI-Private-Key-Flag", 101056528)
$t.Put("msPKI-Template-Schema-Version", 4)
$t.Put("msPKI-Template-Minor-Revision", 2)
$t.Put("msPKI-Certificate-Name-Flag", 1)
$t.Put("msPKI-Enrollment-Flag", 0)
$t.Put("msPKI-RA-Signature", 0)
$t.Put("msPKI-MaxIssuingDepth", 0)
$t.Put("msPKI-Cert-Template-OID", "1.3.6.1.4.1.311.21.8.$(Get-Random -Max 9999999).$(Get-Random -Max 9999999)")
$t.Put("pKIDefaultCSPs", @("1,Microsoft Software Key Storage Provider"))
$t.Put("pKIExpirationPeriod", $validity)
$t.Put("pKIOverlapPeriod", $overlap)
$t.Put("pKIExtendedKeyUsage", @("1.3.6.1.5.5.7.3.1"))
$t.PutEx(2, "msPKI-RA-Application-Policies", @("msPKI-Asymmetric-Algorithm`PZPWSTR`ECDSA_P256`msPKI-Hash-Algorithm`PZPWSTR`SHA256`"))
$t.SetInfo()
Write-Host "Cree : RAS-ECDSA-P256" -ForegroundColor Green

# ECDSA P-384
$t = $container.Create("pKICertificateTemplate", "CN=RAS-ECDSA-P384")
$t.Put("displayName", "RAS-ECDSA-P384")
$t.Put("flags", 131680)
$t.Put("revision", "100")
$t.Put("pKIDefaultKeySpec", 2)
$t.Put("msPKI-Minimal-Key-Size", 384)
$t.Put("msPKI-Private-Key-Flag", 101056528)
$t.Put("msPKI-Template-Schema-Version", 4)
$t.Put("msPKI-Template-Minor-Revision", 2)
$t.Put("msPKI-Certificate-Name-Flag", 1)
$t.Put("msPKI-Enrollment-Flag", 0)
$t.Put("msPKI-RA-Signature", 0)
$t.Put("msPKI-MaxIssuingDepth", 0)
$t.Put("msPKI-Cert-Template-OID", "1.3.6.1.4.1.311.21.8.$(Get-Random -Max 9999999).$(Get-Random -Max 9999999)")
$t.Put("pKIDefaultCSPs", @("1,Microsoft Software Key Storage Provider"))
$t.Put("pKIExpirationPeriod", $validity)
$t.Put("pKIOverlapPeriod", $overlap)
$t.Put("pKIExtendedKeyUsage", @("1.3.6.1.5.5.7.3.1"))
$t.PutEx(2, "msPKI-RA-Application-Policies", @("msPKI-Asymmetric-Algorithm`PZPWSTR`ECDSA_P384`msPKI-Hash-Algorithm`PZPWSTR`SHA384`"))
$t.SetInfo()
Write-Host "Cree : RAS-ECDSA-P384" -ForegroundColor Green

certutil -SetCAtemplates "+RAS-RSA-4096"
Start-Sleep -Seconds 5
certutil -SetCAtemplates "+RAS-ECDSA-P256"
Start-Sleep -Seconds 5
certutil -SetCAtemplates "+RAS-ECDSA-P384"

Étape 2 — Sélection de l’algorithme ECDSA (GUI obligatoire)

Ouvrir certtmpl.msc et pour chaque template ECDSA : onglet Cryptography → sélectionner ECDSA_P256 (ou P384) dans le dropdown → Apply. C’est le seul clic manuel de toute la procédure.

Étape 3 — Publication des templates ECDSA

certutil -SetCAtemplates "+RAS-ECDSA-P256"
Start-Sleep -Seconds 5
certutil -SetCAtemplates "+RAS-ECDSA-P384"

Étape 4 — Génération du certificat ECDSA P-256

[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=ras.votre-domaine.lan"
KeyAlgorithm = ECDSA_P256
KeyLength = 256
HashAlgorithm = SHA256
MachineKeySet = TRUE
Exportable = TRUE
RequestType = PKCS10
[Extensions]
2.5.29.17 = "{text}dns=ras.votre-domaine.lan"

certreq -new C:tempp256.inf C:tempp256.csr
certreq -submit -attrib "CertificateTemplate:RAS-ECDSA-P256" C:tempp256.csr C:tempp256.cer
certreq -accept C:tempp256.cer

Note RSA 4096 : si vous obtenez une erreur ERR_SSL_KEY_USAGE_INCOMPATIBLE, générez la CSR depuis OpenSSL avec les extensions Key Usage explicites (digitalSignature, keyEncipherment) et soumettez-la ensuite à votre CA ADCS.

Envie de voir RASInsider en priorité dans les actualités de Google ?