Weet niet of iemand kan helpen: SSTP VPN-problemen met CRL

Hallo allemaal!

Ik hoop echt dat iemand me kan helpen begrijpen wat er aan de hand is met een SSTP RRAS VPN-server die we hebben opgezet in Windows Server 2016. Het gekke is dat alles op zaterdag en zondag goed werkte en dat het sinds vanochtend niet meer werkt.

Om meteen het voor de hand liggende uit te sluiten, willen we een certificaatintrekkingscontrole gebruiken, dus het installeren van de NoCertRevocationCheck-registersleutel is geen werkende oplossing.

Wat ik heb gedaan:

Gereed RRAS geïnstalleerd en werkende NPS-regels ingesteld. Je kunt verbinden met de server via PPTP, SSTP (als je de intrekkingscontrole uitschakelt) en IKEv2 (met hetzelfde certificaat).

Ik heb onze Enterprise CA ingesteld met een CRL-distributiepunt dat extern bereikbaar is. De CRL-bestanden zijn aanwezig (inclusief het delta-bestand). Ik heb op dezelfde locatie een AIA-punt ingesteld en het CRT-bestand staat daar. Het is misschien belangrijk om te vermelden dat ik de bestanden op een Apache-webserver heb staan.

Ik heb een certificaat aangevraagd en geïnstalleerd van onze Enterprise CA. De algemene naam staat op de DNS-naam van de VPN-server, ik heb een alternatieve DNS-naam in het certificaataanvraag gebruikt die dezelfde naam gebruikt. Opmerking: de interne en publieke namen van de server zijn hetzelfde (VPN03.example.com) – ik heb Extended Key Usage ingesteld voor Server Authenticatie en IP-beveiliging IKE-intermediate. Het certificaat is ingeschreven, en ik heb gecontroleerd dat RRAS dat certificaat gebruikt voor SSTP. Bij het openen en controleren van het certificaat zie ik dat de CRL- en AIA-informatie aanwezig zijn, en ik kan beide locaties openen vanaf zowel internetclients (niet verbonden met VPN) als de VPN-server.

Mijn klantcomputers hebben de root CA geïnstalleerd.

Bij het proberen te verbinden krijg ik de meest voorkomende fout dat de “revocatiefunctie niet in staat was om de intrekking te controleren omdat de revocatieserver offline was”. Online gecontroleerd, zijn de twee meest gebruikelijke oplossingen het uitschakelen van de revocatiecontrole op mijn clients (dit werkt, maar is geen ideale oplossing) en het inschakelen van double escaping in IIS. Omdat ik de CRL- en CRT-bestanden op een Apache-server heb, weet ik niet of ik daar iets moet doen.

Ik heb wat info bijgevoegd die in mijn certificaten staat. Ik kan Wireshark-logs bijvoegen indien nodig.

Waar we bij het werk een beetje vastzitten is dit:

Als een client een verbinding initieert, lijkt de VPN-server de AIA-locatie te controleren op OSCP-info. Het gaat door een dans van het krijgen van een 404 op het CRT-bestand, en daarna het vinden ervan, en daarna weer een 404 krijgen en het weer vinden.

Mijn client-PC lijkt nooit contact op te nemen met de CDP om de CRL-bestanden te krijgen. Ik heb geen idee waarom. Is het zo dat de client dat bestand moet ophalen, of moet de VPN-server dat zelf doen?

Ik heb online gezocht naar een flowchart of een goede beschrijving van wat een SSTP-verbinding moet doen, maar ik heb niet veel gevonden.

CRL-info van het servercertificaat:

[1] CRL-distributiepunt

 Distributiepuntnaam:

      Volledige naam:

           URL=ldap:///CN=example-DC-1-CA,CN=dc-1,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint (ldap:///CN=example-DC-1-CA,CN=dc-1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=example,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint)

           URL=http://crl.example.com/CertEnroll/example-DC-1-CA.crl

AIA-informatie van het servercertificaat:

[1] Authority Info Access

 Toegangs methode=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)

 Alternatieve naam:

      URL=ldap:///CN=example-DC-1-CA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com?cACertificate?base?objectClass=certificationAuthority (ldap:///CN=example-DC-1-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=example,DC=com?cACertificate?base?objectClass=certificationAuthority)

[2] Authority Info Access

 Toegangs methode=Online Certificate Status Protocol (1.3.6.1.5.5.7.48.1)

 Alternatieve naam:

      URL=http://crl.example.com/CertEnroll/dc-1.example.com_example-DC-1-CA(1).crt

Van mijn geheugen moet je CRL toegankelijk zijn voor de client voordat de VPN wordt opgebouwd. Voor mij betekent dat dat ik het AIA en CRL extern publiceer (op een webserver).

Kun je voor de test de bestanden opslaan op een Windows-server of je CA-server internettoegankelijk maken (voor 5 minuten) met de bestanden op de $CRL-share die voor de client beschikbaar zijn? Ik heb het jaren geleden opgezet, maar niet met Apache en herinner me dat er bepaalde machtigingen op de CRL-share/distributiepunt moesten worden ingesteld.

Heb je het hier geprobeerd: https://blogs.technet.microsoft.com/nexthop/2012/12/17/updated-creating-a-certificate-revocation-list-distribution-point-for-your-internal-certification-authority/

Heb je ooit een oplossing gevonden voor dit probleem? Ik heb hetzelfde probleem.

Bedankt voor je reactie.

De AIA en CRL zijn beide toegankelijk via internet via de apache-server. Ik kan een browser openen en de bestanden downloaden voordat ik verbinding maak met de VPN.

Ik had het vermoeden (superstitie, niets meer) dat OCSP niet hetzelfde is als het beschikbaar maken van de CRT/CRL op een webserver - dat er meer “intelligentie” nodig is. Dat zou kunnen betekenen dat de AIA niet extern toegankelijk is op de manier die de certificaatclient verwacht - je webbrowser kan het downloaden, maar de OCSP-gezinde client stuurt een OCSP-verzoek en krijgt niets terug. Misschien kun je dat ondersteunen met de Apache-toegangslog, misschien?

Hmm…

In de war door het knutselen heb ik de AIA-instellingen uit het certificaat gehaald.

Mijn Apache-logs tonen geen inkomende verbindingspogingen van mijn externe client of de VPN-server tijdens de poging tot verbinding.

Ik ben in de war.

Ik heb zeker toegang gezien van clients - zou het kunnen dat de toegangslogboekfunctie voor die Apache-instantie is uitgeschakeld? Of misschien wordt het door een load balancer of iets dergelijks in front van Apache gecached?