none
IKE failed to find valid machine certificate RRS feed

  • Question

  • Hello,

    I'm trying to setup a VPN connection using the following settings:

    • VPN Type: IKEv2
    • Authentication: use machine certificate
    • DHGroup: ECP256 or ECP384

    When I try to connect this VPN, I get the following error: 

    Connecting to vpn.contoso.org.
    Verifying username and password...IKE failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.

    When I change the configuration to DHGroup 'Group14', the connection succeeds.

    The error only occurs when using one of the ECPxxx DHGroups.

    Below is the command output, which shows the working scenario + config update + failing scenario:

    PS C:\> Set-VpnConnectionIPsecConfiguration -ConnectionName vpn.contoso.org -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup group14 -AuthenticationTransformConstants sha256 -CipherTransformConstants AES256 -PfsGroup PFS2048 -force -passthru
    
    AuthenticationTransformConstants : SHA256128
    CipherTransformConstants         : AES256
    DHGroup                          : Group14
    IntegrityCheckMethod             : SHA256
    PfsGroup                         : PFS2048
    EncryptionMethod                 : AES256
    
    PS C:\> rasdial vpn.contoso.org
    Connecting to vpn.contoso.org...
    Verifying username and password...
    Registering your computer on the network...
    Successfully connected to vpn.contoso.org.
    Command completed successfully.
    
    PS C:\> rasdial vpn.contoso.org /disconnect
    Command completed successfully.
    
    PS C:\> Set-VpnConnectionIPsecConfiguration -ConnectionName vpn.contoso.org -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ecp256 -AuthenticationTransformConstants sha256 -CipherTransformConstants AES256 -PfsGroup PFS2048 -force -passthru
    
    AuthenticationTransformConstants : SHA256128
    CipherTransformConstants         : AES256
    DHGroup                          : ECP256
    IntegrityCheckMethod             : SHA256
    PfsGroup                         : PFS2048
    EncryptionMethod                 : AES256
    
    PS C:\> rasdial vpn.contoso.org
    Connecting to vpn.contoso.org...
    Verifying username and password...IKE failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.

    The VPN server is configured to accept any of the following DHGroups: Group14, ECP256, ECP384.

    When I attempt to connect using a different DHGroup, I get a completely different error:

    PS C:\> Set-VpnConnectionIPsecConfiguration -ConnectionName vpn.contoso.org -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup group2 -AuthenticationTransformConstants sha256 -CipherTransformConstants AES256 -PfsGroup PFS2048 -force -passthru
    
    AuthenticationTransformConstants : SHA256128
    CipherTransformConstants         : AES256
    DHGroup                          : Group2
    IntegrityCheckMethod             : SHA256
    PfsGroup                         : PFS2048
    EncryptionMethod                 : AES256
    
    PS C:\> rasdial contoso.org
    Connecting to vpn.contoso.org...
    Verifying username and password...Policy match error

    When I try to connect in with Group14, but have no certificate installed, I also get the 'IKE failed to find valid machine certificate' error.

    It looks like the certificate requirements are different when using one of the ECPxxx DHGroups.

    I tried deleting/recreating certificate, with different settings:

    • client authentication
    • client authentication + server authentication
    • all key usages + all EKU's

    but I was unable to establish a connection.

    I did found a document explaining certificate requirements for the server-side, but not for the client-side certificate.

    Do you have any idea, on how to fix this?

    Thursday, March 15, 2018 8:44 PM

All replies

  • Let’s search solution from here.

    Setup IKEv2/Windows 10

    https://github.com/hwdsl2/setup-ipsec-vpn/issues/106

    Regards


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

    Friday, March 16, 2018 2:06 AM
    Moderator
  • Hello

    Hello, I have the same problem as you when I use the DH GROUP 19 (ECP 256) or 20 (ECP 384).

    I have a certificate error.

    Connecting to vpn.contoso.org...
    Verifying username and password...IKE failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.

    Have you been able to unlock the situation?

    Patrick
    Friday, June 22, 2018 7:17 AM
  • I can confirm this behavior. PfsGroup can be switched to ECP384 without problems. But as soon as I switch DHGroup to ECP384 the clients are unable to establish the VPN.

    Configuration:
    Windows 10 Pro v1803
    IPFire v2.21 Build 123
    IKEv2 using Machine Certificates

    AuthenticationTransformConstants : SHA256128
    CipherTransformConstants         : AES256
    DHGroup                          : Group2 (ECP384 not working)
    IntegrityCheckMethod             : SHA256
    PfsGroup                         : ECP384
    EncryptionMethod                 : AES256


    • Proposed as answer by Patrick97470 Thursday, September 27, 2018 1:16 PM
    • Edited by Michael Biber Thursday, September 27, 2018 2:30 PM Typo
    Thursday, September 27, 2018 11:22 AM
  • Hi, 

    I faced the same problem when i setup my VPN infrastructure, it was throwing error with an eventid 20227 and error code The error code returned on failure is 13806. The issue was caused by unavailability of the Certificate in the local store of the VPN Server. After i install the necessary Certs in the VPN server certifcate store, the error dissappeared

    the below troubleshooting link explains the error code 13806 as well. https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy-troubleshooting

    Thanks

    Shajeer


    Shajeer.K Windows Infrastructure

    Friday, January 4, 2019 4:10 PM
  • Given how thoroughly the original question was researched (including "deleting/recreating certificate, with different settings"), the suspicion that a certificate with an ECDSA key may be required probably arises and indeed turns out to be the case. This requirement is an artifact of the Microsoft implementation rather than the IKEv2 protocol itself.

    RFC 4754 (IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)) says in section 1:

       For any given level of security against the best attacks known, ECDSA
       signatures are smaller than RSA signatures, and ECDSA keys require
       less bandwidth than DSA keys [LV]; there are also advantages of
       computational speed and efficiency in many settings.  Additional
       efficiency may be gained by simultaneously using ECDSA for IKE/IKEv2
       authentication and using elliptic curve groups for the IKE/IKEv2 key
       exchange.  Implementers of IPsec and IKE/IKEv2 may therefore find it
       desirable to use ECDSA as the Phase 1/IKE-AUTH authentication method.

    Microsoft has taken this advice earnestly.

    When machine certificate authentication is used, the Microsoft implementation hard couples the detailed IKEv2 authentication mechanism to the DH group used in the IKE_SA_INIT message. For DH-ECP-256 (group 19) an Auth Method of 9 (ECDSA with SHA-256 on the P-256 curve) is sent in the Authentication Payload; for DH-ECP-384 (group 20) an Auth Method of 10 (ECDSA with SHA-384 on the P-384 curve) is sent; for the other DH groups supported by Microsoft an Auth Method of 1 (RSA Digital Signature) is sent.

    This process of choosing an authentication method takes place when the IKEv2 tunnel is configured (by calling FwpmIPsecTunnelAdd2) in the BFE (Base Filtering Engine) and before a search of available/suitable certificates is performed. The BFE IKEv2 phase 1 (main mode) provider context that is configured when a DH group of ECP256 is specified looks like:

    <providerContext>
      <providerContextKey>{dbf328e9-0dc8-49d6-9b24-62ad1152c5d2}</providerContextKey>
      <displayData>
        <name>IKEv2 Client Main mode IPsec tunnel policy</name>
        <description/>
      </displayData>
      <flags/>
      <providerKey/>
      <providerData/>
      <type>FWPM_IPSEC_IKEV2_MM_CONTEXT</type>
      <ikeV2MmPolicy>
        <softExpirationTime>0</softExpirationTime>
        <authenticationMethods numItems="3">
          <item>
            <authenticationMethodType>IKEEXT_CERTIFICATE_ECDSA_P256</authenticationMethodType>
            <certificateAuthentication>
              <inboundConfigType>IKEEXT_CERT_CONFIG_TRUSTED_ROOT_STORE</inboundConfigType>
              <inboundTrustedRootStoreCriteria/>
              <outboundConfigType>IKEEXT_CERT_CONFIG_TRUSTED_ROOT_STORE</outboundConfigType>
              <outboundTrustedRootStoreCriteria numItems="2">
                <item>
                  <certData/>
                  <certHash/>
                  <eku>
                    <numEku>2</numEku>
                    <eku numItems="2">
                      <item>1.3.6.1.5.5.7.3.2</item>
                      <item>1.3.6.1.5.5.8.2.2</item>
                    </eku>
                  </eku>
                  <name/>
                  <flags/>
                </item>
                <item>
                  <certData/>
                  <certHash/>
                  <eku>
                    <numEku>1</numEku>
                    <eku numItems="1">
                      <item>1.3.6.1.5.5.7.3.2</item>
                    </eku>
                  </eku>
                  <name/>
                  <flags/>
                </item>
              </outboundTrustedRootStoreCriteria>
              <flags/>
              <localCertLocationUrl/>
            </certificateAuthentication>
          </item>
          <item>
            <authenticationMethodType>IKEEXT_CERTIFICATE</authenticationMethodType>
            <certificateAuthentication>
              <inboundConfigType>IKEEXT_CERT_CONFIG_TRUSTED_ROOT_STORE</inboundConfigType>
              <inboundTrustedRootStoreCriteria/>
              <outboundConfigType>IKEEXT_CERT_CONFIG_UNSPECIFIED</outboundConfigType>
              <flags/>
              <localCertLocationUrl/>
            </certificateAuthentication>
          </item>
          <item>
            <authenticationMethodType>IKEEXT_CERTIFICATE_ECDSA_P384</authenticationMethodType>
            <certificateAuthentication>
              <inboundConfigType>IKEEXT_CERT_CONFIG_TRUSTED_ROOT_STORE</inboundConfigType>
              <inboundTrustedRootStoreCriteria/>
              <outboundConfigType>IKEEXT_CERT_CONFIG_UNSPECIFIED</outboundConfigType>
              <flags/>
              <localCertLocationUrl/>
            </certificateAuthentication>
          </item>
        </authenticationMethods>
        <initiatorImpersonationType>IKEEXT_IMPERSONATION_NONE</initiatorImpersonationType>
        <ikeProposals numItems="1">
          <item>
            <cipherAlgorithm>
              <algoIdentifier>IKEEXT_CIPHER_AES_256</algoIdentifier>
              <keyLen>0</keyLen>
              <rounds>0</rounds>
            </cipherAlgorithm>
            <integrityAlgorithm>
              <algoIdentifier>IKEEXT_INTEGRITY_SHA_256</algoIdentifier>
            </integrityAlgorithm>
            <maxLifetimeSeconds>28800</maxLifetimeSeconds>
            <dhGroup>IKEEXT_DH_ECP_256</dhGroup>
            <quickModeLimit>0</quickModeLimit>
          </item>
        </ikeProposals>
        <flags numItems="1">
          <item>00000080</item>
        </flags>
        <maxDynamicFilters>100</maxDynamicFilters>
        <retransmitDurationSecs>1800</retransmitDurationSecs>
      </ikeV2MmPolicy>
      <providerContextId>9223372036854776074</providerContextId>
    </providerContext>

    Although 3 authentication methods are included in the context, only the first specifies a valid outboundConfigType.

    The ECDSA key length of the certificate used has to match the DH group length.

    Gary

    Saturday, January 5, 2019 4:39 PM