Let’s encrypt: binding, ADFS et certificats

Je pars du principe que votre ADFS est fonctionnel :

Serveur ADFS – OK
Serveur Microsoft WAP – OK
un certificat auto-signé attaché au WAP

Si tout fonctionne « bien » lorsque vous prenez un ordinateur lambda (un mac dans un Apple store par exemple), n’importe quel navigateur va raller parce que le certificat n’est pas reconnu.
Si vous utilisez un certificat Let’s encrypt … pas de problème et pas de warning.
Maintenant, je vous expose le souci.
J’utilise ADFS pour publier plusieurs services (Exchange, Guacamole – j’en parlerais dans un billet, wordpress, LAMP, etc…). Je voulais aussi accédera un VPN SSL (type SSTP). Et pour se faire, il n’y a (à ma connaissance) que ADFS qui sache le faire.

Maintenant, je peux utiliser un certificat «payant » valide 1 ou 2 ans et le « jumeler » avec mon ADFS (une importation dans la banque perso des certificats SSL et hop, il sera disponible en tant que certificat pour ADFS).

Si je passe par Let’s encrypt vu que le certificat doit etre renouvelé tous les 3 mois … ma fainéantise aidant je ne me voyais pas le mettre à jour à la main.

 

Voila comment faire !!!!

Pour que l’astuce fonctionne, vous devez nommer vos règles ADFS-WAP du nom de votre service.
Par exemple pour https://exchange.titi.com … la règle va se nommer exchange.titi.com.

Il faut un serveur IIS (ou server cert) qui est disponible via le firewall sur port 80 !!!! et qui soit capable de répondre à tous vos préfixes de domaine.

Donc un site :

exchange.titi.com en C:\InetPub\WWWRoot
lamp.titi.com en C:\InetPub\WWWRoot
iis.titi.com en C:\InetPub\WWWRoot

C’est aussi ce serveur qui va générer et renouveler les certificats (on va voir ça plus tard).
Il faut un autre serveur qui est le serveur WAP classique que vous utilisez déjà sur le port 443 (ou server wap)

 

Farm server et Central SSL store

Il faut installer sur les 2 serveur central SSL store (c’est une option de sécurité d’IIS).
Vous choisissez un nom de dossier identique pour server cert et server wap.
Une fois bien paramétré vous avez un Central SSL store sur les 2 serveurs et c’est le partage de fichier windows de server cert qui permet à server wap de voir les certificats.
Pour le moment c’est vide.

Il va falloir fabriquer un server farm. Cela va permettre à Let’s encrypt de valider votre demande de certificat. Let’s encrypt vérifie la présence d’une ligne de caractère dans un fichier pour valider que vous êtes le propriétaire du site qui demande le certificat.

Dans le Farm Server vous fabriquer une première « ferme » sur server wap que j’appelle par exemple reponse-cert et une deuxième regle reponse-wap

Vous remontez sur le serveur web IIS et cliquer sur URL-rewrite.

VOUS DEVEZ METTRE AU 1ER NIVEAU LA REGLE reponse-cert et l’editer
Rien ne doit changer sauf pattern qui de * va devenir

.well-known/acme-challenge/*

Sur le server cert, il faut telecharger https://github.com/Lone-Coder/letsencrypt-win-simple (et aller sur download version … le code source ne nous intéresse pas).

Pour ce tuto, je decompresse le contenu de letsencrypt-win -simple dans c:\ letsencrypt-win

Et puis on va créer le certificat.

–          Il faut créer C:\InetPub\WWWRoot\.well-known\acme-challenge (un petit mkdir c’est plus simple)

–          Puis copier Web_Config.XML dans C:\InetPub\WWWRoot\.well-known\acme-challenge\ et le renommer en Web_Config

–          Nous allons créer un certificat maintenant qui utilise SAN (nom alternatif) et central SSL store

–          letsencrypt –san –centralsslstore \\ server_cert\nom_de_mon_partage

–          vous vous laissez guider tout du long de la procédure jusqu’à

W: Generate a certificate via WebDav and install it manually.
F: Generate a certificate via FTP/ FTPS and install it manually.
M: Generate a certificate manually.
A: Get certificates for all hosts
Q: Quit

–          choisissez M (pour manually)

–          entrez titi.com

–          puis exchange.titi.com,lamp.titi.com,iis.titi.com

–          puis C:\InetPub\WWWRoot\

–          vous acceptez la création de tâche

Normalement tout devrait bien se dérouler et vos certificats se retrouve sur

\\ server_cert\nom_de_mon_partage

Et magie ils sont aussi dans l’ISS central cert de server wap.

Ce dernier contient déjà les règles ADFS reverse proxy suivante :

exchange.titi.com https://exchange.titi.com  certificatADFS https://exchange.titi.com
lamp.titi.com https://lamp.titi.com  certificatADFS https://lamp.titi.com
iis.titi.com https://iis.titi.com  certificatADFS https://iis.titi.com

 

et là … magie de powershell, nous allons importer les certificats du partage \\ server_cert\nom_de_mon_partage dans le gestionnaire personnel de certificat puis changer pour chaque WAP le certificat qui va bien.

$CentralStore = "\\FSCluster\SSLStore"
$TargetPath = "C:\CertifyVault"
$SharePath = "\c$\CENTSERV"
$TargetServers = @("server_wap")

ForEach ($Target in $TargetServers) {
  New-Item -ItemType Container ("\\" + $Target + $SharePath) -ErrorAction SilentlyContinue
  Copy-Item $CentralStore\* ("\\" + $Target + $SharePath) -Recurse

  $TargetSession = New-PSSession -ComputerName $Target -Authentication Kerberos

  Invoke-Command -Session $TargetSession -ScriptBlock {
  param($TargetPath)
  $CertFiles = Get-ChildItem -Path $TargetPath -Filter '*.pfx'
  ForEach ($CertFile in $CertFiles) {
  $Certificate = (Import-PfxCertificate -FilePath $CertFile.FullName -CertStoreLocation Cert:\LocalMachine\My -Verbose)
  $Thumbprint = $Certificate.ThumbPrint
  ForEach ($DNSName in $Certificate.DnsNameList) {
  $Subject = $DNSName.Punycode
  Get-WebApplicationProxyApplication -Name $Subject -Verbose | Set-WebApplicationProxyApplication -ExternalCertificateThumbprint $Thumbprint -Verbose
  }
  }
  } -ArgumentList $TargetPath

  Remove-PSSession -Session $TargetSession
}

 

Et là si tout se passe bien (normalement ca devrait) vous avez les certificats let’s encrypt qui vont remplacer les certificats ADFS sur vos règles de reverse proxy WAP.

La ou c’est encore plus magique c’est que cette règle tourne tous les jours (n’oubliez pas de créer une tâche qui lance le script) et remplace le certificat tous les jours.

La tâche lié au certificat tourne elle aussi tous les jours et le certificat (qui n’est valable que 3 mois) se retrouve renouvelé pour 3 mois ….tous les mois. Cela laisse une bonne marge.

 

VOILA vous avez un ADFS avec let’s encrypt totalement automatisé.
Pas belle la vie ?

Let’s encrypt – SSL c’est quoi ? et ADFS ?

Vous connaissez tous SSL/TLS ?
Non ?

Voilà ce qu’en dit Wikipédia

TLS (ou SSL) fonctionne suivant un mode client-serveur. Il permet de satisfaire aux objectifs de sécurité suivants :

  • L’authentification du serveur ;
  • la confidentialité des données échangées (ou session chiffrée) ;
  • l’intégrité des données échangées ;
  • de manière optionnelle, l’authentification du client (mais dans la réalité celle-ci est souvent assurée par le serveur).

 

En gros, cela permet d’afficher un petit cadenas vert dans le navigateur et de garantir que le serveur en face communique de façon sécurisé avec votre navigateur.

 

Concernant Let’s Encrypt (et toujours Wikipédia)

Let’s Encrypt est une autorité de certification lancée le 3 décembre 2015 (qui est sorti de Beta il y a quelques mois). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d’un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l’installation et le renouvellement des certificats pour la sécurisation des sites internet.

L’avantage la gratuité. L’inconvénient, le certificat doit être renouvelé tous les 3 mois et qu’ils font donc l’attacher à vos serveurs. Si en plus le dit serveur est un IIS ou un service Microsoft …s’pas facile.

MAIS … MAIS … il y a une petite solution bien sympa et qui fonctionne avec ADFS.

Que permet ADFS … de fabriquer entre autre un reverse proxy intelligent.
Le reverse proxy permet d’interpréter les adresses web pour le relayer vers une machine d’un LAN.

C’est-à-dire.
Admettons que j’ai le nom de domaine titi.com.
Admettons que j’ai 3 machines avec exchange, un apache sous linux et un serveur IIS quelconque.
Admettons qu’elles servent toutes un service sur le port 443 ou SSL/TLS.

Soit j’expose chaque machine avec un port différent (nattage par port). C’est crade.
Soit j’utilise mon ADFS pour dire que exchange.titi.com va sur l’Exchange, apache.titi.com va sur le serveur Apache et iis.titi.com va sur le serveur IIS le tout sur un seul port 443.

C’est mieux non. Sans compter qu’il devient possible avec ADFS d’utiliser SSTP (le VPN SSL de Microsoft) 3 machines différentes en 443 sur le même port !
La ça devient TOP !!!

Dans un prochain billet, je vous expliquerais comment.