locked
IPSEC/L2TP with PEAP Auth fails with error 860 RRS feed

  • Question

  • Hello everyone,

    after setting up an offline Root-CA together with a new Enterprise CA I'm expiriencing problems on IPSEC/L2TP VPN connections that authenticate with PEAP.

    The setup is as follows:

    • DC is NPS
    • RRAS server is in DMZ
    • Root-CA's certificate is published to AD/Web - Enterprise PKI does not show errors
    • Signing CA's certificate is also published to AD/Web
    • AIA and CDP are configured and work
    • Just for the NPS I created a certificate from the RAS/IAS template, containing the Lan-FQDN as CN and both the LAN-FQDN and the public FQDN as SAN. That certificate is used in the apropriate policy.

    On the VPN client when I open the certificate of the NPS, everything seems OK, the certificate is trusted, the Root CA's certificate is in the trusted CAs store of the computer and the Signing CA's certificate is in the Intermediate CAs store.

    I can connect using PEAP without server validation. As soon as I activate server validation - with the Root CA checked in the client settings - i get the error 860 and the connection is terminated.

    Is there any way to get to know why the validation fails?
    Friday, February 16, 2018 9:04 PM

All replies

  • Hi,

    ERROR 860: The remote access connection completed, but authentication failed because of an error in the certificate that the client uses to authenticate the server

    There is a solution for you,please note what Mervyn Zhang said

    https://social.technet.microsoft.com/Forums/en-US/1e38f81d-a154-4096-a0e9-3e44ae1f0315/vpn-connection-failed?forum=winserverNAP

    Best Regards,

    Frank


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com


    Monday, February 19, 2018 2:18 AM
  • https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-cert-requirements

    Is the SAN the FQDN of the NPS server? I would try just the DNS name on the LAN.

    Sunday, February 25, 2018 6:24 AM
  • Thanks for answering.

    The SAN of the NPD server contains the LAN DNS of the NPS Server and the Public DNS of the RRAS server. The CN of the same certificate is the LAN DNS.

    The certificate itself I could verify, the thumbprint matches.

    The problem is that the client does not verify the certificate. When I turn of certificate verification then the connection works. Concerning the link you posted, I verified this twice:

    • The Subject name contains a value. ==> it contains the LAN DNS
    • The computer certificate on the server chains to a trusted root certification authority (CA) ==> the Root-CA is trusted and the issuing CA in the computer Intermediate CAs store
    • and does not fail any of the checks that are performed by CryptoAPI and that are specified in the remote access policy or network policy ==> none defined
    • The computer certificate for the NPS server or VPN server is configured with the Server Authentication ==> it is
    • The server certificate is configured with a required algorithm value of RSA ==> Algorithm is sha256RSA, Public key is 2048 bits
    • The Subject Alternative Name (SubjectAltName) extension, if used, must contain the DNS name of the server. ==> it does contain internal and external DNS.

    Cheers,

    Thomas

    Sunday, February 25, 2018 9:28 AM
  • Hmm I think I recall something that might be the issue here.

    It used to be OK to have the issuing CA in the intermediate CA store as long as it chained correctly to a root CA that was in trusted roots, but this changed at some point and you now have to make sure the issuing CA is in the trusted root store.

    The actual requirements are that at least one of the two are true:

    1. The certificate is found in the Enterprise NTAuth store.
    2. The certificate is found in the client's Trusted Root Certification Authorities container, and it is marked as trusted

    -------

    So, I'd recommend just adding the CA to the trusted roots.  If you want to try adding the cert to NTAuth the info below should help.

    -------------

    You can view the NTAuth store with:

    certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=C

    To import a CA certificate into the Enterprise NTAuth store, follow these steps:

    Export the certificate of the CA to a .cer file. The following file formats are supported:

    • DER encoded binary X.509 (.cer)
    • Base-64 encoded X.509 (.cer)

    At a command prompt, type the following command, and then press ENTER:

    certutil -dspublish -f filename NTAuthCA

    The contents of the NTAuth store are cached in the following registry location:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates

    This registry key should be automatically updated to reflect the certificates that are published to the NTAuth store in the Active Directory configuration container. This behavior occurs when Group Policy settings are updated and when the client-side extension that is responsible for autoenrollment executes.

    In certain scenarios, such as Active Directory replication latency or when the Do not enroll certificates automatically policy setting is enabled, the registry is not updated.

    In such scenarios, you can run the following command manually to insert the certificate into the registry location:

    certutil -enterprise -addstore NTAuth CA_CertFilename.cer



    Sunday, February 25, 2018 8:33 PM
  • Thank you for your response. I just added the Issuing CA's certificate to the Trusted Root CAs container - the behaviour is still the same. Is there any way to get a more detailed logging?
    Sunday, February 25, 2018 9:03 PM
  • Remove the external DNS name from the SAN.  I've seen problems before when you try to add multiple names. It should just contain the internal DNS name, assuming that the CA is reachable internally at that name.
    Sunday, February 25, 2018 9:11 PM
  • Well, the CAPI2 log gave me a clue, that was a missing link. The verification failes because the revocation status could not be verified, but not only the LDAP stores (which are not accessible from outside), but also the HTTP-store (CRL is published to that URI and could be retrieved using a browser). I'll take a further look tomorrow. Thank you so far, I'll post updates here.
    Sunday, February 25, 2018 9:35 PM