Archives mensuelles : avril 2017

Pourquoi ADCS ne délivre des certificats que de deux ans maximum?

Lorsqu’on une installe une PKI même pour un usage purement technique, on a la tentation de réaliser l’installation via l’interface graphique, en se passant de fichiers CAPolicy.Inf et Policy.Inf. C’est ce que j’ai encore fait cette semaine et c’était une erreur. Dans mon cas, le besoin semblait simple, pourtant, je suis tombé sur un os : Pourquoi ma PKI refuse de me délivrer des certificats d’une durée de vie de plus de deux ans ? Il m’a fallu quelques minutes pour réaliser mon erreur. En l’absence de précision, une installation « Quick/Next/Finish » utilise les valeurs par défaut. Donc sans expression de besoin, il nous faut aller explorer la base de registre :

Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

clip_image001

En creusant, la configuration, j’ai retrouvé les deux paramètres en relation avec mon problème :

  • ValidityPeriod
  • ValidityPeriodUnits

Le besoin exprimé étant de pouvoir délivrer des certificats d’une durée de vie de trois ans, une petite reconfiguration s’impose. Réalisé à l’ancienne, cela donne cela :

CertUtil.Exe -SetReg CA\ValidityPeriodUnits 3

CertUtil.Exe -GetReg CA\ValidityPeriodUnits

clip_image002

Après un redémarrage du service de l’autorité de certification, mon problème était corrigé. Conclusion, même pour une PKI à usage technique, il faut toujours préparer la mise en œuvre d’une autorité de certification.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Multiples adresses IP par carte réseau dans Azure

Pendant longtemps, Azure nous a limité dans le nombre d’adresses IP que l’on pouvait associer à une seule interface réseau : Une adresse IP publique et une adresse IP privée. La seule solution pour avoir plusieurs adresses IP publiques sur une même machine virtuelle était d’avoir plusieurs adresses IP publiques. Quand on travaille avec des Virtual Appliances dans Azure, c’était une limitation majeure dans le cas de Kemp, ma VLM Kemp ne pouvait avoir qu’une seule VIP. Il n’était pas possible de cumuler plusieurs Virtual Services utilisant chacun une adresse IP publique distincte. La fonctionnalité est GA depuis un peu plus d’un mois, voyons concrètement comment la mettre en œuvre avec la création d’une interface réseau dans les règles de l’art :

Je pars du principe que le Virtual Network existe. On va récupérer les informations le concernant avec la commande « Get-AzureRmVirtualNetwork » :

$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName Network -Name AdatumVnet

$vnet

clip_image001

 

Dans ce Virtual Network, je sais qu’il y a un Subnet nommé « Adatumsubnet ». On va en avoir besoin car c’est à un subnet qu’une interface réseau est lié :

$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name Adatumsubnet -VirtualNetwork $vnet

$subnet

clip_image002

 

Pour que notre interface réseau puisse avoir plusieurs adresses IP, nous devons mettre en place plusieurs configurations IP. Chaque configuration IP étant composée d’une adresse IP privée voire d’une adresse IP publique. Commençons par créer notre première adresse IP publique :

$publicIP1 = New-AzureRMPublicIpAddress -name « MyPublicIP1 » -ResourceGroupName Network -Location « West Europe » -AllocationMethod static

$publicIP1

clip_image003

 

Nous avons une adresse IP publique, passons à l’adresse IP privée. Par défaut, le DHCP d’Azure nous fournirait la première adresse IP disponible sur le subnet. J’ai fait le choix d’avoir une adresse IP privée statique. La commande « New-AzureRmNetworkInterfaceIpConfig » permet de créer notre première configuration IP dans la variable $Ipconfig1.

$IpConfig1 = New-AzureRmNetworkInterfaceIpConfig -Name « Ipconfig1 » -Subnet $subnet -PrivateIpAddress ‘192.168.1.10’ -PublicIpAddress $PublicIP1 -Primary

$IpConfig1

clip_image004

 

La seconde configuration IP sera beaucoup plus simple, avec uniquement une adresse IP privée allouée en mode dynamique :

$IpConfig2 = New-AzureRmNetworkInterfaceIpConfig -Name « Ipconfig2 » -Subnet $subnet

$IpConfig2

clip_image005

 

Note : On voir bien la différence avec la première configuration IP. La propriété « PrivateIpAllocationMethod » est ici configurée à « Dynamic » alors que pour la première interface, elle était configurée à « Static ».

 

Nous avons tous les éléments pour créer notre interface réseau comprenant nos deux configurations IP. Nous connaissons déjà la commande « New-AzureRMNetworkInterface ».

$NIC = New-AzureRMNetworkInterface -Name « NetworkInterface » -ResourceGroupName Network -Location ‘West Europe’ -IpConfiguration $IpConfig1, $IpConfig2

$NIC

clip_image006

 

Une fois la création terminée, on doit pouvoir constater les résultat suivant dans le portail :

  • Notre interface réseau dispose bien de deux configurations IP
  • La première comprend une adresse IP privée statique et une adresse IP publique elle aussi en statique
  • La seconde comprend uniquement une adresse IP privée allouée dynamiquement

 

clip_image007

 

Dans mon exemple, nous avons simplement illustré le fait d’avoir plusieurs configuration IP. Si nous voulions avoir plusieurs adresses IP publiques associées à une seule interface réseau, il aurait juste fallu avoir plusieurs configuration IP, chacune ayant une adresse IP publique associée.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)