Point-to-Site on Windows 8 Client connection Error 798


  • Hello,

    Install Certificate and Client Package and when I try to connect it shows the following error

    "A certificate could not be found that can be used with this Extensible Authentication Protocol. (Error 798) For customised troubleshooting information for this connection"

    I have checked both cert are installed under current user in both personal and trusted root, and have tried every resource we can

    We have successfully installed using same settings & process on Windows 7 without problem, the log file is as follows

    Operating System      : Windows NT 6.2 
    Dialler Version        : 7.2.9200.16384
    Connection Name       : Dxxxxxxxxx2
    All Users/Single User : Single User
    Start Date/Time       : 16/05/2013, 15:04:48
    Module Name, Time, Log ID, Log Item Name, Other Info
    For Connection Type, 0=dial-up, 1=VPN, 2=VPN over dial-up
    [cmdial32] 15:04:48 22 Clear Log Event
    [cmdial32] 15:04:51 04 Pre-Connect Event ConnectionType = 1
    [cmdial32] 15:04:51 06 Pre-Tunnel Event UserName =  Domain =  DUNSetting = Dxxxxxxxxx2 Tunnel DeviceName =  TunnelAddress =

    Thursday, May 16, 2013 2:09 PM


All replies

  • Did you ever discover a solution for this? I'm testing now and running into the same issue with Windows 8. I generated my testing certificate with makecert per this:


    Noah Stahl

    Thursday, May 30, 2013 2:49 AM
  • Hi Noah,

    I have encountered the same issue using Windows 8.

    Mike Nooney

    PayGlobal Ltd.

    Saturday, July 20, 2013 9:26 AM
  • Same issue here, has anyone figured this out yet?
    Tuesday, July 23, 2013 11:15 PM
  • Just had the same issue.

    What I did is to Install the Client certificate ( a second  time!) .. but this one specifying explicit the "personal" store.

    Do know what made the difference (imho this should be the Default anyway) .. but after that it worked.

    Wednesday, July 24, 2013 2:55 PM
  • Hi

    I tried this approach with no luck. So you installed the client cert into Current User -> Personal?

    Also I find that the second time I try to connect the Remote Access Dialer crashes. I.e. 2 Error 798 messages.

    Could you possibly list the steps you went through to get it working?



    Saturday, July 27, 2013 5:23 AM
  • I am also experiencing that error, with windows 8.

    Any workaround?

    Monday, July 29, 2013 10:47 AM
  • Hi Pedro

    I tried again with a different Windows 8 machine. It worked this time when I placed the client cert

    into Current User -> Personal store.

    The VPN client connected first time without any Error 798 message.

    However it seems once I went down the wrong track on the first machine I could not correct it.



    Monday, July 29, 2013 7:39 PM
  • Hi Pedro

    I tried again with a different Windows 8 machine. It worked this time when I placed the client cert

    into Current User -> Personal store.

    The VPN client connected first time without any Error 798 message.

    However it seems once I went down the wrong track on the first machine I could not correct it.

    Thanks for the insight!

    The problem is that I went for the wrong track on my personal machine, and I am not able to correct it by putting into the Personal Store.  Going to another machine is not an option on this case.

    Creating another network could correct it, but would imply creating the virtual machines from scrach.

    Is Microsoft aware of this bug in the VPN implementation? 

    It is strange since it is on the newest version of the flagship operating system... not particularly a niche case, I would guess.

    Tuesday, July 30, 2013 4:57 PM
  • Any update from Microsoft support?

    I have the same issue on Windows 8 and Windows Server 2008

    Wednesday, July 31, 2013 8:55 PM
  • Problem solved on my side!!

    I was only creating the "server certificate", the one that is uploaded to azure.

    You need to create a "cliente certificate" as well.

    Please find instructions in the following post (you will have to search it since I am not able to post links): 

    Setting up point-to-site VPN certificates


    Monday, August 05, 2013 5:17 PM
  • Hi,

    I am facing the same problem with windows 8.1.

    I have installed a second time but doesn't work.

    Is there any solution for this problem?



    Sunday, October 27, 2013 9:36 AM
  • Hi guys. any news so far?

    Same issue here with Windows 8.1

    I'm also surprised to see the vpn executable doesn't pass the windows smart screen filtering but I don't care

    just wanna see the Point-to-Site VPN working!



    Tamir Levy

    Sunday, November 24, 2013 9:22 PM
  • Hi all,

    I had the same issue but found a work around. Perform the following steps after you create certificates, upload a root certificate, and install a VPN package as guided in MSDN site:

    1. Run ncpa.cpl and confirm a target FQDN of a VPN connection for Point-To-Site which begins with "azuregateway" in detail view.
    2. Create a VPN connection manually from "Network and Sharing Center" with the target FQDN.
    3. Open properties of the manually-created VPN connection.
    4. In "Authentication" of "Security" tab, select "Use Extensible Authetincation Protocol" and "Microsoft: Smart Card or other certificate", and click "Properties".
    5. In "When connecting", select "Use a certificate on this computer".
    6. Click "OK" to close a dialog.
    7. In "Networking" tab, select "Internet Protocol Version 4" and click "Properties".
    8. Click "Advanced" and uncheck "Use default gateway on remote network".
    9. Click "OK" thrice to close all dialogs
    10. Start the manually-created VPN connection. If you are required to select a certificate, select the client certificate you created. And you need to accept the connection target only at the first time.

    Note: After the manually-created VPN connection worked well once, the VPN connection created by package installation also worked well in my environment. What a mystery...


    • Edited by Yutaka, N Saturday, February 08, 2014 10:14 AM
    Saturday, February 08, 2014 9:44 AM
  • Thank you! Now working.
    Sunday, February 09, 2014 6:50 AM
  • I am on a client machine. After an attempt to connect using those steps exactly, I am on my way when I get this:

    I had the VPN set to "automatic" (no change from default) and I got "error 800: the remote connection was not made because the attempted VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parameters required for IPsec negotiation might not be configured properly."

    Also when I try to ping the IP associated with the azure gateway in terminal it fails.

    Monday, February 10, 2014 4:04 PM
  • Here is the solution.

    Make sure you have already created your Root and Client Certificate.  If not, perform these steps following instructions from

    • Root Certificate: makecert -sky exchange -r -n "CN=AZMgmtRootCert" -pe -a sha1 -len 2048 -ss My "AZMgmtRootCert.cer"
    • Client Certificate: makecert.exe -n "CN=AZMgmtClientCert" -pe -sky exchange -m 96 -ss My -in "AZMgmtRootCert" -is my -a sha1

    Make sure the AZMgmtRootCert.cer file is uploaded to the Virtual Network Certificates section.

    Now from the workstation that created those certificates:

    1. Load MMC, Add the "Certificates" Snap In for "My user account".
    2. Go into Personal / Certificates
    3. Right click on "AZMgmtRootCert" -> All Tasks -> Export
    4. Export the Private Key as a part of the process, but keep the rest of the defaults.
    5. Name it as AZMgmtClientCert.pfx

    On the workstation that you want to allow to connect (even Windows 8 / 8.1 workstations)

    1. Install AZMgmtRootCert.cer (Place the certificate in the "Personal" Certificate Store) 
    2. Install AZMgmtClientCert.pfx (Place the certificate in the "Personal" Certificate Store)

    You should now be able to connect to the Virtual Network on that workstation.

    • Proposed as answer by darielmarlow Wednesday, October 26, 2016 7:12 PM
    Friday, May 02, 2014 10:52 PM
  • I'm experiencing this same issue. I followed the directions to use makecert.exe to generate the self-signed root certificate, and the client VPN certificate. Does the client certificate have to be exported, if I'm using the VPN connection from the same computer that I'm connecting from?

    Trevor Sullivan
    Microsoft PowerShell MVP

    If this post was helpful, please click the little "Vote as Helpful" button :)

    Trevor Sullivan
    Trevor Sullivan's Tech Room
    Twitter Profile

    Monday, May 05, 2014 5:45 PM
  • Hi Jason,

    Are you saing the server certificate shuld allso be install on the client ?

    Friday, May 30, 2014 6:49 PM
  • Ok, just had this issue.

    Solution for me was the make sure it was a user certificate and not a computer one!

    I used my own CA, uploaded the CA cert to Azure and created a user cert for the client.

    Worked fine. Doesnt work with a computer cert!


    Sunday, June 08, 2014 4:12 PM
  • I have tried all the recommendations here. I got the manual vpn connection answer to work connect but still cannot see my servers in the virtual network. I would like an answer to this quickly as I am thinking about switching to amazons cloud service.  Windows 8.1 Pro.


    • Edited by eenuckols Friday, June 20, 2014 7:11 AM
    Friday, June 20, 2014 7:10 AM
  • Hey Yutaka! I dont get your solution. What is a FQDN and when i run ncpa.cpl only the network connection page will open. On my client Win 7 I got an connection to Azure VPN but on my Win 8.1 client the error appears (798) no certification found.



    Wednesday, July 02, 2014 2:55 PM
  • After about an hour of working through the MS instructions, I found your solution.  You have just enough additional detail to get my VPN Certificates setup correctly.  Thanks, Jason.  You get my vote.


    • Edited by Mario5280 Wednesday, August 13, 2014 10:39 PM
    Wednesday, August 13, 2014 10:13 PM
  • The solution is installing the root .cer in addition to the client .pfx.

    Thanks Jason!

    Monday, September 08, 2014 8:30 AM
  • The solution is installing the root .cer in addition to the client .pfx.

    Thanks Jason!

    I still have this issue with Windows 8.1, and I'm not able to solve it even after installing the root .cer. This is really pathetic considering MS can't get their OWN VPN, to their OWN cloud, on their OWN OS. Ridiculous.
    Thursday, October 15, 2015 8:17 AM
  • Be sure that you are using the PERSONAL store for the client-side Cert. Once you have imported the cert, VIEW IT to be sure that it is valid.  The error that I had is that I am running UTC on the CA server and the client was on EST.  So, the cert wasn't valid for another 5 hours (doh).  I adjusted the time on the client and it worked. 

    MMC / Add/remove snap-in, Certificates / My User account / Personal > All tasks/ Import

    Also, when you export the client cert from MMC in the CA, make sure you select the option to export the private key. 

    Friday, October 16, 2015 5:45 PM
  • I have the same issue, when i try with W7 it works, but when i use W8 i have two situations, the first one is if i use W8 in 64bit, i have to create the network manually and it works, i tried in W8 32bits and it doesn't work, the problem i have is just in machines with Windows 10 32bit and Windows 8 32 bits

    Any solutions for this ?

    The solutions for W8 64bits i found here

    Wednesday, January 06, 2016 2:00 PM
  • Hi Dani,

    Just being pedantic, did you download the correct version(s) of the Azure P2S VPN client packages? There are 32 and 64 bit versions for the same P2S VPN.


    Yushun [MSFT]

    Thursday, January 14, 2016 9:48 PM
  • Although none of the other solutions here worked for me, I was able to work out a (slightly unsatisfactory) way to work around this problem.

    In my case, the way the certificate was installed was not a problem, because the exact same cert was working fine for me with a different VPN. So none of the proposed fixes around making sure the certificate was installed in the right place was going to change anything - it already was. Although that apparently fixed it for some, there's a completely different reason you can get this 798 error.

    When you run the installer that the Azure portal generates, it creates some files and a folder in your %APPDATA%\Microsoft\Network\Connections\Cm\. There will be a <guid>.cmp file where <guid> is the same one that's in the hostname for the VPN gateway, and there will also be a <guid> folder. Inside that will be the various icons and banners presented for this connection, a <guid>.cer which is the certificate the server will use, various other files, and, most importantly, a <guid>.cms.

    This <guid>.cms file contains lots of settings controlling various aspects of the connection, one of which appears to be information determining which certificates will be shown from the picker UI. Each of the Azure VPN connections I have on my system shows a slightly different list of certs, and it appears to be determined by settings in this file of the form CustomAuthDataN, where N is 0, 1, 2, etc, and the number of entries varies from one connection to another.

    I've been unable to find any documentation about the data format used by these entries. However, I've got one connection which always shows all the certificates for which I have private keys, and I've found that if I copy its data across to another .cms file, that will start doing the same thing. So if you're in a situation where you're getting a 798 error for a particular connection, you could try replacing all of the CustomAuthDataN lines with this:


    You only need that one line, so if you had any CustomAuthData1, CustomAuthData2, etc, remove those.

    This is not ideal if you have a lot of certs for which you have private keys because it will show you everything, but it may get you to a point where you can at least connect.

    • Proposed as answer by Igor CZ Wednesday, June 29, 2016 8:26 PM
    Wednesday, February 10, 2016 3:25 PM
  • Thanks for the tip about the CustomAuthData0 entry.  One of our users was receiving the same "A certificate could not be found that can be used with this Extensible Authentication Protocol. (Error 798) For customised troubleshooting information for this connection" error with the correct client certificate in her personal store.  She received the same error on two different machines where she had local admin rights.  I used the same certificate and same exe (with inf, cms, and other files for vpn interface installation) on both machines without any issues.  I did a directory/file comparison between our %APPDATA%\Microsoft\Network\Connections\Cm\ and the only file different was that <guid>.cms which only seemed to have CustomAuthData0, 1, and 2 line entries in different order.  The values appeared to be the same with 2 being blank.  Since I was out of other ideas I went ahead and tried your suggestion for the CustomAuthData0 and it immediately worked for her.  This fixed it for her on both of those machines.  I'm still unclear on what caused the deviation between our implementations.  We are both local admins on those boxes and went through the exact steps in installing the client cert and vpn connection.  Anyway thanks for sharing that tip.
    Thursday, March 17, 2016 9:20 PM
  • IanG your solution worked perfectly. On my windows 10 machine it never showed the certificate dropdown dialog to pick the certificate.
    Tuesday, July 19, 2016 8:46 PM
  • IanG, your solution works on windows server 2012.Thanks

    Wednesday, August 10, 2016 8:42 PM
  • It's late into 2016, ran into this problem still with the P2S VPN. Ian's suggestion works, but is not ideal. Anyone else find other ways to make this work?
    Wednesday, November 02, 2016 4:31 PM
  • Open the failed VPN connection and go to "advanced options" click "edit" and save the value of server name or address somewhere.

    Open network and sharing center, click "set up a new connection or network", "connect to a workplace", "no, create a new connection", "use my internet connection", on "internet address" paste the value saved before, uncheck "remember my credentials", check "use a smartcard", click "create".

    On your adapter settings (on network and sharing center" you'll have the new vpn connection, right-click, properties. On the security tab click properties on the authentication area, select the radio box "use a certificate on this computer and uncheck "verify the server's identity by validating the certificate":

    Click OK.

    Unlike the connection created by Azure install file, this connection can be renamed.

    In practice we are creating a VPN connection manually instead of using the Azure file.

    By default you'll lose access to everything else while connected, you can fix that playing with the windows routing table and disabling the option to use the connection default gateway ("networking" tab, IPv4 advanced properties).

    P.S.: DON'T install the server certificate on clients as suggested somewhere on a post marked as answer here. This is a critical security breach. Clients only need the client certificate (hence the name).

    Marco Alves
    Azure Infrastructure Consultant


    Please "Mark As Answer" if my post solves your problem or "Vote As Helpful" if the post has been helpful to you. - This will encourage me and others to keep helping you :)

    Note: This post is offered "as is" and reflects my opinion on this specific thread. It confers no rights. It does not necessarily represent my employer's opinion.

    Friday, November 18, 2016 11:24 AM
  • This solution worked perfectly, it appears the effects both Windows 8.1 and Windows 10.

    I have also created a script which you can run to correct the issue. 

    #Set-ExecutionPolicy Unrestricted
    Write-Host -ForegroundColor Green "[$(Get-Date -Format hh:mm:ss)] Locating Profile..."
    cd "$env:APPDATA\Microsoft\Network\Connections\Cm\"
    $filename = (Get-ChildItem -Directory).Name
    cd $filename
    sleep -Milliseconds 700
    Write-Host -ForegroundColor Green "[$(Get-Date -Format hh:mm:ss)] Loading Profile file..."
    $data = Get-Content -path "$filename.cms"
    sleep -Milliseconds 700
    $linenumbers = $data | select-string -Pattern 'CustomAuthData' | select LineNumber
    $firstline = ($linenumbers[0].LineNumber)-1
    foreach($line in $linenumbers.LineNumber){
    $data[($line-1)] = ""
    sleep -Milliseconds 700
    $data[$firstline] = "CustomAuthData0=314442430D0000002A000000020000002A0000001700000000000000000000000000000000000000000000000000000000000000000000000000"
    remove-item -path "$filename.cms"
    Write-Host -ForegroundColor Green "[$(Get-Date -Format hh:mm:ss)] Writing File..."
    $data | out-File -FilePath ".\$filename.cms"  -Encoding ascii -Force 
    sleep -Milliseconds 1300
    Write-Host -ForegroundColor Cyan "[$(Get-Date -Format hh:mm:ss)] Please try to connect using the Azure VPN Client"
    #Set-ExecutionPolicy Restricited

    Friday, November 25, 2016 5:05 PM
  • If you have a Windows 10\2016, try:

    New-SelfSignedCertificate -CertStoreLocation "Cert:\CurrentUser\My\" -Subject -KeySpec KeyExchange -TestRoot -KeyUsage DigitalSignature

    Then you need to move the "CertReq Test Root" from Intermediate CA to Trusted Root CA and import it too to Azure Gateway.

    You can use these certificate ( to manage your Azure thru PowerShell to. Just import it at Settings>Management Certificates.

    Good luck!

    Thursday, January 26, 2017 1:48 PM
  • Thanks for this.
    It worked for me :)

    For windows8
    need to open this first :
    run - %APPDATA%\Microsoft\Network\Connections\Cm\.

    there it will have 1 folder and 1 .cmp file

    then need to open the folder and find .cms file

    open that with any file editor and find the line starting with "CustomAuthData0 ="

    replace that with this line "CustomAuthData0=314442430D0000002A000000020000002A0000001700000000000000000000000000000000000000000000000000000000000000000000000000"

    then try to connect and it will work for windows 8.
    Monday, March 06, 2017 1:34 PM
  • Fought with this for days, but using the PowerShell instructions on Windows 10 always resulted in a 798 error ("A certificate could not be found that can be used with this Extensible Authentication Protocol. (Error 798)") without any prompt for which certificate to use.
    Creating the VPN manually worked, as did manually changing the CustomAuth0 string, both undesirable as manual hacks to something that should have worked without such workarounds.
    I finally tried creating a second parallel certificate using the MakeCert instructions and it popped up the prompt first try asking me to select between the two certificates.  I picked the PowerShell one that previously only created errors and it worked fine.  I deleted the MakeCert one, and everything continued to work fine.  I deleted the connection and reinstalled the client configuration and it continues to work fine.  Something not quite right about all this, as in theory nothing changed from previous failures; yet the MakeCert instructions have miraculously fixed my PowerShell certificates, even after the MakeCert certificates were removed.  Weird.

    Tuesday, July 25, 2017 6:11 PM