Anmelden
 
HomeLibraryDownloadsSupportWebcasts & EventsCommunityForenBlogs
Ressourcen für IT-Professionals >
> 
> 
Can't establish IKEv2 VPN connection - "Error 13819: Invalid certificate type"

Unanswered Can't establish IKEv2 VPN connection - "Error 13819: Invalid certificate type"

  • Freitag, 23. November 2012 13:01
     
     
    Anmelden
    0

    I'm trying to make a VPN connection to a Windows Server 2012 Essentials server. I can successfully connect using SSTP, but I want to use IKEv2 to improve performance. However, when I try to connect, I receive the following error messsage: "Error 13819: Invalid certificate type".

    The message suggests to me that the certificate being used does not have the correct EKU attributes for an IKEv2 connection. However, I have issued a certificate for the server, placed in the server's Personal Store, which includes the EKUs for Server Authentication and IP security IKE Intermediate, as specified in this tutorial (albeit for Server 2008) The certificate is self-signed, with the root authority trusted by the client computers.

    What I would like to do is to find out exactly which certificate is actually being selected by the server for the IKEv2 connection. I can't see any way of verifying which is being used - I suspect the server may be selecting a different certificate without the correct EKUs. Once I am sure of the certificate being used, I could verify it on the client computers with certutil.

    Could anyone suggest how I could do that?

    Thanks.

     

Alle Antworten

  • Montag, 26. November 2012 06:36
    Moderator
     
     
    Anmelden
    0

    Hi,

    Thanks for posting in Microsoft TechNet forums.

    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

    Thank you for your understanding and support.

    Regards

    Kevin

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.

     
     
  • Montag, 26. November 2012 08:02
     
     
    Anmelden
    0
    Hi,

    Please refer to the article below for checking the certificate on the VPN server:

    Troubleshooting IKEv2 VPN Connections
    http://technet.microsoft.com/en-us/library/dd941612(v=ws.10).aspx

    If you have any concern, please feel free to let me know.

    Thanks.
    Best Regards,
    Annie Gu
     
  • Freitag, 30. November 2012 16:52
     
     
    Anmelden
    0

    Hi Annie,

    Thanks for your response. I've already seen the article, and my certificate already appears to match all the requirements mentioned in it. My specific error, 13819, is not mentioned.

    What I want to do is to find out how to determine which certificate is actually being used. I know that a valid certificate is available, I just don't know whether the server is correctly using it. Is there a way to specify which certificate the server should use? I was under the impression that the server simply selects whichever certificate it finds to be valid (has the correct EKUs, etc.).

    Thanks.



     
  • Freitag, 7. Dezember 2012 14:30
     
     
    Anmelden
    0

    An update: Following the instructions here, I have changed the SSTP certificate (although it was working fine) to the certificate I have issued for IKEv2 use, since I believe I can use it for both of them. I have also deleted the old SSTP certificate, which should mean that there is only one certificate that can be used for the connection.

    There is no change - SSTP still works fine, but IKEv2 still fails with "Error 13819: invalid certificate type."

    Is there any way I can gather more information about the problem, beyond the rather basic error message?

    I still suspect that the IKEv2 connection is somehow using the wrong certificate.

    Thanks,

    Andrew


     
  • Donnerstag, 13. Dezember 2012 07:50
     
     
    Anmelden
    0

    Hi,

    Which type of templated you used for applying the certificate?

    As I know, there are three versions to apply the certificate: version1, version2 and version 3.

    Usually,the version 3 template doesn't apply to some application. If you used the version 3, can we change to version 1 or 2 for test?

    Thanks.

    Annie

     
  • Freitag, 14. Dezember 2012 13:05
     
     
    Anmelden
    0

    Hi,

    Which type of templated you used for applying the certificate?

    As I know, there are three versions to apply the certificate: version1, version2 and version 3.

    Usually,the version 3 template doesn't apply to some application. If you used the version 3, can we change to version 1 or 2 for test?

    Thanks.

    Annie

    Hi Annie,

    To issue the certificate I've been creating a template as outlined here: http://technet.microsoft.com/en-us/library/dd637815%28v=ws.10%29.aspx#bkmk_step4

    I can't see any reference to version 1/2/3 in the details of the certificate template. Where should I look for this?

    Thanks,

    Andrew

     
  • Montag, 17. Dezember 2012 09:32
     
     
    Anmelden
    0

    Hi,

    Can we delete all the other certificate except this problematic one on a test client?

    I would like to test if the certificate will be incorrectly taken by the computer or not.

    Thanks.

    Best Regards,

    Annie

     
  • Donnerstag, 20. Dezember 2012 06:09
     
     
    Anmelden
    0

    I'm glad to see that someone else is having the same issue, and is working on the result.  I'd be happy to do some tests as well on our server if that would help.

    Symptoms are similar in that IKEv2 will fail with the same error 13819 from my Windows 8 desktop, however, it connects just fine from my Windows 7 desktop.  Clients who connect to our network via VPN to perform some tasks have been reporting similar issues, however, it's not as clear cut as Win8 never works and Win7 always works.  They're getting failures on Windows 7 as well.

    Certificate wise, this server has a wildcard certificate on it from Thawte, for *.ourdomain.com, and VPN connections are made to a hostname that matches this wildcard.  SSTP has no problems at all.  PPTP is functioning as well.  We aren't using L2TP/IPSEC.  The server is RRAS on Windows Server 2012.

    I recently had the need to do some internally signed certificates for some client's test sites, so I have installed certificate services and made this a standalone CA, so there's a self signed ca certificate (ca.ourdomain.com), which does overlap with the wildcard certificate, but since the wildcard one doesn't allow certificate signing the self signed one is in there.

    Under RRAS there's an option with SSTP as to which certificate to use, nothing of the kind for IKEv2.  Just to make sure there's not a certificate problem with the wrong one being automatically chosen, I've installed the CA self signed certificate as a trusted root certificate on my Windows 8 desktop, and attemtped to establish a VPN to ca.ourdomain.com instead of vpn.ourdomain.com.

    The server has two IP addresses configured on the LAN adapter and I've checked with "netsh http show sslcert" to ensure they're bound to the correct IPs.

    I will double check that last part though since there were some hotfixes applied recently and a server reboot.  I have noticed these bindings change from time to time.

    Alex.

     
  • Freitag, 28. Dezember 2012 10:58
     
     
    Anmelden
    0

    I'm glad to see that someone else is having the same issue, and is working on the result.  I'd be happy to do some tests as well on our server if that would help.

    Symptoms are similar in that IKEv2 will fail with the same error 13819 from my Windows 8 desktop, however, it connects just fine from my Windows 7 desktop.  Clients who connect to our network via VPN to perform some tasks have been reporting similar issues, however, it's not as clear cut as Win8 never works and Win7 always works.  They're getting failures on Windows 7 as well.

    Hi Alex,

    Interesting to hear your experience. I'm also having problems with connecting on a Windows 7 client, but it's interesting that some of your clients are successfully connecting.

    I had assumed that "invalid certficate type" referred to the server certificate. Perhaps that's not the case, if some clients can connect. Is it an intermittent fault in your case? Do some clients connect sometimes, but not always?

    @Annie: Which certificate do you mean for me to preserve on the client? In theory, there shouldn't need to be any certificates on the client (aside from the root authority's), surely?

    Andrew

     
  • Mittwoch, 2. Januar 2013 16:55
     
     
    Anmelden
    0

    Hi,

    Can we delete all the other certificate except this problematic one on a test client?

    I would like to test if the certificate will be incorrectly taken by the computer or not.

    Thanks.

    Best Regards,

    Annie

    Hi Annie,

    I have just tried to connect through the StorngSwan VPN client on an Android phone. In the log, I can see I'm receiving the same error - 13819. There are no certificates installed on the phone.

    Andrew

     
  • Montag, 4. Februar 2013 11:59
     
     
    Anmelden
    0

    I am afraid I am still experiencing this problem. How can I confirm which certificate is being selected by the server for the IKEv2 connection?

    Thanks,

    Andrew

     
  • Dienstag, 5. Februar 2013 13:33
     
     
    Anmelden
    0

    to run IKEv2 you need the following EKUs on both server and client certificates. The machines select certificates automatically, the best option is the a), if not present, they proceed to the next b) and c):

    a)IPSec IKE Intermediate (IPSec Protection) 1.3.6.1.5.5.8.2.2 + Server Authentication + Client Authentication
    b)IPSec IKE Intermediate + Client Authentication
    c)Client Authentication

    As you may see, both client and server require Client Authentication EKU in the certificate. If you include Server Authentication and IKE Intermediate, you will get more exact match.

    ondrej.

     
  • Mittwoch, 6. Februar 2013 12:31
     
     
    Anmelden
    0

    to run IKEv2 you need the following EKUs on both server and client certificates. The machines select certificates automatically, the best option is the a), if not present, they proceed to the next b) and c):

    a)IPSec IKE Intermediate (IPSec Protection) 1.3.6.1.5.5.8.2.2 + Server Authentication + Client Authentication
    b)IPSec IKE Intermediate + Client Authentication
    c)Client Authentication

    As you may see, both client and server require Client Authentication EKU in the certificate. If you include Server Authentication and IKE Intermediate, you will get more exact match.

    ondrej.

    Hi ondrej,

    Thanks for the reply. I've reissued the certificate with the Client Authentication EKU, but it hasn't made any difference.

    Please note that I'm not using machine certificates on the client for authentication - I want to use Secure Password (EAP-MSCHAPv2), which is working when I connect through SSTP. However, the server seems to be determined to use certificates for client authentication - when I log using wfp, in the wfpdiag.xml file I can see that the authentication method listed is <mmAuthMethod>IKEEXT_CERTIFICATE</mmAuthMethod>. As I understand it, this should not be the case.

    How can I get the server to accept EAP-MSCHAPv2 authentication?

    Thanks,

    Andrew

     
  • Donnerstag, 7. Februar 2013 05:49
     
     
    Anmelden
    0

    I actually don't think it is possible to have ikev2 without client machine certificate. According to my understanding, there are two distinct authentications. First, the client machine needs to establish ikev2 tunnel. For this, you need two ikev2 certificates - one on the VPN server, the other on the client machine - in the machine profile, not in user store, these certificates must adhere to ikev2 requirements. Once your client computer has ikev2 channel established, only then come PPP authentication - in your case the desired eap-tls with password. For this, you need to have a tls server certificate on NPS/RADIUS (in its policy, ragardless it is the same machine as the VPN server) - this would be tls "server authentication" certificate, again stored in the machine store and selected in the NPS network policy in the eap-tls settings.

     
  • Freitag, 8. Februar 2013 16:15
     
     
    Anmelden
    0

    I actually don't think it is possible to have ikev2 without client machine certificate. According to my understanding, there are two distinct authentications. First, the client machine needs to establish ikev2 tunnel. For this, you need two ikev2 certificates - one on the VPN server, the other on the client machine - in the machine profile, not in user store, these certificates must adhere to ikev2 requirements. Once your client computer has ikev2 channel established, only then come PPP authentication - in your case the desired eap-tls with password. For this, you need to have a tls server certificate on NPS/RADIUS (in its policy, ragardless it is the same machine as the VPN server) - this would be tls "server authentication" certificate, again stored in the machine store and selected in the NPS network policy in the eap-tls settings.

    Hi Ondrej,

    Thanks for your reply. I'm using EAP-MSCHAPv2, not EAP-TLS, by the way. May I ask you, are you 100% sure that the client machine also needs a certificate? You see, this IKEv2 connection is now working on a Windows 7 client that does not have a client certificate. Yet if I try the same connection details on a Windows 8 client, I still get error 13819. The only difference I can see is that in Event Viewer, on the Windows 8 client that fails, it says that "The user SYSTEM dialed a connection", even if the connection was only created for my own user account, whereas the Windows 7 client says something like "The user WORKPC/Andrew dialed a connection." I don't know it it's relevant, but it's the only way I can see that it differs.

    If you have some documentation pointing to the need to have certificates on both client and server, I would appreciate seeing it.

    Thanks,

    Andrew


     
  • Mittwoch, 6. März 2013 13:08
     
     
    Anmelden
    0

    It's been three months and I still haven't found a solution. It works on a Windows 7 client but not on Windows 8 clients, both of which seem to be set up the same way. What further testing can I do? Is this a bug in Windows 8?

     
  • Mittwoch, 6. März 2013 18:00
     
     
    Anmelden
    0

    Hi Ondrej,

    Interestingly, today I looked in the server's certificate store again and saw two certificates for my RRAS server's external name (e.g. vpn.microsoft.com), one being my old certificate with just the EKUs for Server Authentication and IKE Intermediate, and the other having Client Authentication as well.

    I deleted the one with all three EKUs, and my Windows 7 client stopped working - with error 13819.

    So it looks as if the Client Authentication is needed. However, it still won't work on Windows 8.

    Furthermore, there may be another issue here, because when I re-issued the certificate with all three EKUs (and deleted the one with 2 EKUs), my Windows 7 client won't connect, even though it should be just the same set-up as before.

    I suspect that the server is still somehow using the wrong certificate - maybe one of my other server certificates. How can I tell which certificate it is selecting?

    Thanks,

    Andrew