DirectAccess-clients kunnen mogelijk geen verbinding maken met een DirectAccess-server met een fout 0x800b0109 bij het gebruik van IP-HTTPS

Dit artikel biedt een oplossing voor een probleem waarbij DirectAccess-clients geen verbinding kunnen maken met een server met behulp van IP-HTTPS.

Oorspronkelijk KB-nummer: 2980667

Symptomen

DirectAccess-clients kunnen mogelijk geen verbinding maken met een DirectAccess-server met behulp van IP-HTTPS. Wanneer u de netsh interface http show interface opdracht uitvoert, ziet de uitvoer er als volgt uit:

URL: Fout: https://da.contoso.com:443/IPHTTPS 0x800b0109
Interfacestatus: Kan geen verbinding maken met de IPHTTPS-server. Wachten om opnieuw verbinding te maken

De fout 0x800b0109 wordt omgezet in:
CERT_E_UNTRUSTEDROOT
# Een certificaatketen is verwerkt, maar beëindigd in een basismap
# certificaat dat niet wordt vertrouwd door de vertrouwensprovider.

Standaard is het certificaatarchief vertrouwde basiscertificeringsinstanties geconfigureerd met een set openbare certificeringsinstanties die worden vertrouwd door een Windows-client. Sommige organisaties willen mogelijk certificaatvertrouwen beheren en voorkomen dat gebruikers in het domein hun eigen set vertrouwde basiscertificaten configureren. Daarnaast willen sommige organisaties certificaten uitgeven voor de IP-HTTPS-server van hun eigen certificeringsinstantieserver. Ze moeten dat specifieke vertrouwde basiscertificaat distribueren om de vertrouwensrelaties mogelijk te maken. Bij het configureren van certificaten voor DirectAccess moet de basiscertificeringsinstantie worden vertrouwd door de clients en moet het basis-CA-certificaat zich in het archief vertrouwde basiscertificeringsinstanties bevinden.

Zie Hoe certificaatintrekking werkt voor meer informatie over certificaten.

Oorzaak

De verlenende certificeringsinstantie voor het IP-HTTPS-certificaat is niet aanwezig in de vertrouwde en tussenliggende archieven van clients. Zorg ervoor dat u het basiscertificaat toevoegt aan het basisarchief en de tussenliggende certificaten aan de tussenliggende archieven.

Oplossing

Volg deze stappen om dit probleem op te lossen:

1. Haal het certificaat op voor de certificeringsinstantie die het IP-HTTPS-certificaat heeft uitgegeven.
2. Importeer dit certificaat in het computerarchief van de DirectAccess-client.
3. Als u deze wijziging wilt toepassen op alle clients, gebruikt u Groepsbeleid om het geïmporteerde certificaat te implementeren.

DirectAccess-connectiviteitsmethoden

DirectAccess-clients gebruiken meerdere methoden om verbinding te maken met de DirectAccess-server, waardoor toegang tot interne resources mogelijk is. Clients hebben de mogelijkheid om Teredo, 6to4 of IP-HTTPS te gebruiken om verbinding te maken met DirectAccess. Dit is ook afhankelijk van hoe de DirectAccess-server is geconfigureerd.

Wanneer de DirectAccess-client een openbaar IPv4-adres heeft, probeert deze verbinding te maken met behulp van de 6to4-interface. Sommige ISP's geven echter de illusie van een openbaar IP-adres. Wat ze eindgebruikers bieden, is een pseudo openbaar IP-adres. Dit betekent dat het IP-adres dat is ontvangen door de DirectAccess-client (een gegevenskaart of SIM-verbinding) mogelijk een IP-adres is van de openbare adresruimte, maar in werkelijkheid zich achter een of meer NAT's bevindt.

Wanneer de client zich achter een NAT-apparaat bevindt, wordt geprobeerd Teredo te gebruiken. Veel bedrijven, zoals hotels, luchthavens en koffiebars, staan Teredo-verkeer niet toe om hun firewall te passeren. In dergelijke scenario's voert de client een failover uit naar IP-HTTPS. IP-HTTPS is gebouwd via een OP SSL (TLS) TCP 443 gebaseerde verbinding. Uitgaand SSL-verkeer wordt waarschijnlijk toegestaan op alle netwerken.

Met dit in gedachten is IP-HTTPS gebouwd om een back-upverbinding te bieden die betrouwbaar en altijd bereikbaar is. Een DirectAccess-client maakt hiervan gebruik wanneer andere methoden (zoals Teredo of 6to4) mislukken.

Meer informatie over overgangstechnologieën vindt u in IPv6-overgangstechnologieën.