We are upgrading the server from Windows 2003 to 2008. As part of the process, I need to configure a port with a SSL certificate. When I ran the following command:
netsh http add sslcert ipport=1.2.3.4:8000 certhash=certificatehash appid={someGUID}
I got the following error:
SSL Certificate add failed, Error:
1312 A specified logon session does
not exist. It may already have been
terminated.
When running the command prompt with an administrator does not resolve the issue. Notice that I did not run into this issue on Windows 2003 (using httpcfg) and that things work well there.
Has anyone encountered this issue? Thanks.
the 1312 shows up at several occasions. aside from typos on the commandline, the other most common are:
- the certificate is not in your certificate store at all (check with MMC and 'certificates' snap-in)
- the certificate is in the wrong store: it should be in the store of 'local computer' not 'local user' (remember to choose proper account when activating the snapin inside the MMC)
- the certificate doesnt contain a Private Key (open the certificate and check whether it contains only public, or both keys)
I've spent over 1.5 hours before I found out that I've had generated a certificate succesfully, but misplaced some switches and it got written to a file without the private key:)
Are you running from an elevated command prompt (not just as an admin)?. There's an open source GUI tool that drives the HTTP config APIs directly- I use it on 2008 R2 with no trouble (it auto-requests elevation via UAC). I've had mixed results with netsh/httpcfg. This one always works for me (and it behaves the same everywhere).
Related
I have one issue when trying to connect to the LDAP server through code. It works fine when I use admin tool to connect to it.
it works fine when using this admin tool to connect to it.
it doesn't work when I use this code to connect to it, it says
The server could not be contacted. ---> System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
My code:
Using context As DirectoryServices.AccountManagement.PrincipalContext = New DirectoryServices.AccountManagement.PrincipalContext(DirectoryServices.AccountManagement.ContextType.Domain, SingleSignOn.ADDomain, SingleSignOn.ADSecurityGroup, DirectoryServices.AccountManagement.ContextOptions.SecureSocketLayer Or DirectoryServices.AccountManagement.ContextOptions.Negotiate, UserName, Password)
Using foundUser = DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(context, UserName)
Return foundUser IsNot Nothing
End Using
End Using
My question is:
how to set up the code to use version 3?
Thank you in advance for your help/ideas.
Windows needs to trust the SSL certificate, otherwise the connection will fail. Unfortunately the error message doesn't tell you that.
You have a couple options:
Change the certificate being used on the server to a certificate from a trusted root authority. This is the best way to do it, especially if this is a production server.
Tell Windows to trust the self-signed cert. This would have to be done on every computer that will connect. To do this, use the PowerShell script in this answer to download the certificate (change the URL to match your server). This will give you a .cer file. Then follow the instructions here to import it on the computer that you are running this code on. In that article, start at the heading "To start the certificate import process through Microsoft Management Console (MMC)". In step 4, you have the option to import it for the current user only, or for the whole computer (which requires local admin rights).
When installing a self-signed certificate for use in VPN authentication, I ran into an interesting problem: the VPN would successfully authenticate for some time after the installation, but after a reboot I would start getting the following message:
Error 798: A certificate could not be found that can be used with this Extensible Authentication Protocol
(I actually wrote a full question while I was debugging this, when I didn't know the cause, which you can find here: Some clients can only authenticate to VPN when connecting as Administrator. But to summarize: after a reboot users would start getting this message and from that point the connection could only be established by connecting as Administrator [i.e. running rasphone or rasdial as Administrator].)
It's worth noting that redoing the installation would make the connection work again until the next reboot.
What ended up being important- and the reason this belongs on StackOverflow and not another site- is that I was installing this certificate via code. I had written a program to automate the VPN installation; it did a number of things, one of which was installing the client certificate for authentication. Here is an abbreviated version of the certificate installation code:
Dim Certs As New X509Certificate2Collection()
Certs.Import(PfxFileName, Password, X509KeyStorageFlags.PersistKeySet)
Dim ClientCert, IssuerCert As X509Certificate2
If Certs(0).HasPrivateKey Then
ClientCert = Certs(0)
IssuerCert = Certs(1)
Else
ClientCert = Certs(1)
IssuerCert = Certs(0)
End If
Using Store As New X509Store(StoreName.Root, StoreLocation.LocalMachine)
Store.Open(OpenFlags.ReadWrite)
Store.Add(IssuerCert)
End Using
Using Store As New X509Store(StoreName.My, StoreLocation.CurrentUser)
Store.Open(OpenFlags.ReadWrite)
Store.Add(ClientCert)
End Using
My pfx files always had two certificates: the client's with its private key, and the root without one. The root certificate needed to go in cert:/LocalMachine/Root and the client certificate needed to go in cert:/CurrentUser/My.
Using the above code, the previously stated problem would result.
Using the process of elimination, I ran each part of my custom installation software and found that it was the re-installtion of the certificate alone (using the code above) that caused the connection to temporarily start working again. I then tried installing the certificate manually (by double-clicking the pfx file and using the dialog box).
I found that when I installed the certificate manually, the VPN connection worked stabily, but when I installed it via the previous code, it only worked until my next reboot. This indicated to me that there must be some difference between what my code was doing, and what the dialog box was doing.
And then it hit me: my program is running as Administrator. But the dialog box for adding a certificate to the CurrentUser store never gives a UAC prompt, so it's running under my normal user context.
Now, there are parts of my program that do need to run as Administrator, so I had to rework the whole thing to use two processes (one admin and one non-admin) to do different parts of the installation. I won't get into that here, but once I had it all working I tried running the following part of the code as a non-admin:
Using Store As New X509Store(StoreName.My, StoreLocation.CurrentUser)
Store.Open(OpenFlags.ReadWrite)
Store.Add(ClientCert)
End Using
And it worked! As long as I added the client certificate to the CurrentUser store as a non-admin, the VPN connection was able to consistantly connect across reboots.
I still don't quite understand why running the code as Administrator causes the problems it does. The certificate does appear in the cert:/CurrentUser/My, but it just doesn't work once it's there. Maybe it has something to do with some hidden permissions on the associated private key? That might explain why connecting as Administrator always worked, but not why connecting as a non-admin worked until a reboot occurred.
I am using TFS 2015, I have a Release definition created for my test environment. A task for "PowerShell on Target Machines" has been added. The values are all entered correctly for this such as Machines, Admin Login, Password. HTTPS is the protocol, The Test Certificate checkbox is checked. WinRM listener is already setup on the remote server and working. When I run this task it shows as Rejected.
The error is below:
[error]Connecting to remote server myserver.example.com failed with the following error message : The server certificate on the destination computer (myserver.example.com:5986) has the following errors:
[error]The SSL certificate could not be checked for revocation. The server used to check for revocation might be unreachable. For more information, see the about_Remote_Troubleshooting Help topic.
The TFS agent I am using does not have internet capability. I tried this from another TFS agent that HAS internet capability and it worked.
Does anyone know if the TFS Agent must have internet capability?
Is there a way to skip the revocation checking from the User Interface?
Try to solution here to create and pass a new PSSessionOption object that specifies that all certificate checks should be bypassed.
$sessionOption = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
$session = New-PSSession -ConnectionUri $yourUrl -Credential $credential -Authentication Basic -AllowRedirection -SessionOption $sessionOption
Import-PSSession $session
I am trying to ignore the certificate warning on remote desktop connection - the one in the image:
So far I have found that when I check the "don't ask again" checkbox it is generating registry key over here:
HKCU:\Software\Microsoft\Terminal Server Client\Servers
A new record is generated with the name of the server and key name CertHash that contains a value that is specific for a machine. The key is the same for a machine - if I delete it and check the checkbox the same value is again generated. There is a new value in case I recreate the virtual machine so I think it is something machine specific.
Can someone tell me how is this hash generated so I can populate the key from command line? Adding certificate is not an option and the machines will be frequently regenerated so I need an option to ignore this automatically as I need to connect a user to the machine and run some programs in it.
I know this is an old question. But this may help someone who is looking for the same solution.
Method 1
You may over ride the certificate check for ALL RDP connections (use it at your own risk)
Just add a new registry key as below.
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client" /v "AuthenticationLevelOverride" /t "REG_DWORD" /d 0 /f
Method 2
Considering if you have admin rights on the remote machine, you could actually get the crethash value from the remote machine using the below wmic command. So you could make a small batch file to get this value before you launch the mstsc and add this value in registry. I haven't included the complete batch file but thats the idea.
wmic /node:Testserver /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSGeneralSetting get SSLCertificateSHA1Hash
See this link.
Run Microsoft Management Console (mmc) and add the Certificates snap-in if you don't already have it for the computer you would like to connect to. In the Certificates, find the Remote Desktop folder, and open the certificate in that folder. On the Details tab, scroll down to find the Thumbprint value - this is the value you should copy to the registry.
After setting up HTTPS in IIS Express, according to such articles as this and this, I am unable to actually load an IIS Express site using HTTPS. In Chrome, I am only getting:
This webpage is not available (with error code "ERR_CONNECTION_RESET")
...and in IE I am only getting:
Internet Explorer cannot display the webpage
...when I follow the directions in those articles.
It appears this has to do with the fact that the "IIS Express Development Certificate" that IIS Express installs automatically has been removed. How do I get this certificate reinstalled?
Windows 10 users: Repair is only in the Control Panel, not in the Add Remove programs app. I typically run appwiz.cpl to launch the old control panel applet and run repair from there.
Windows 7 and 8.1:
After going to Add/Remove Programs and choosing the "Repair" option on IIS Express, the certificate has been reinstalled and I can now launch IIS Express sites using HTTPS.
The certificate is back:
And I can now launch the IIS Express site using HTTPS:
For Visual Studio 2015, IIS Express 10, Windows 10, these options didn't work for me. IIS Express 10 didn't have a repair option.
I managed to solve the problem using the IisExpressAdminCmd.exe command available at C:\Program Files (x86)\IIS Express.
From an elevated command prompt run:
cd C:\Program Files (x86)\IIS Express
IisExpressAdminCmd.exe setupsslUrl -url:urlToYourSite -UseSelfSigned
Replacing urlToYourSite with your url.
e.g.
cd C:\Program Files (x86)\IIS Express
IisExpressAdminCmd.exe setupsslUrl -url:https://localhost:44387/ -UseSelfSigned
After that I closed IIS Express and restarted my site from Visual Studio and it prompted to automatically trust the self-signed certificate.
Also note that for IIS Express to work with SSL, the port used needs to be in the 44300 through 44399 range (http://www.iis.net/learn/extensions/using-iis-express/running-iis-express-without-administrative-privileges).
So, if you're using IIS Express in Visual Studio, make sure the port selected is in the required range:
vs setting for iis express
Sometimes this error is because of a different certificate installed for localhost. If that is the case, there is no need to restore the IIS Express certificate. Instead, you can do the following to tell IIS Express to use your existing certificate:
Open the Certificates MMC snap-in as described here
Find your localhost certificate e.g. under Personal...Certicates and get its thumbprint:
Bring up the properties dialog for the localhost certificate and find the Thumbprint property
Paste the thumbprint value into Notepad (or whatever) and remove the spaces and any special characters at the beginning
Find the port value of your IIS Express project:
Go to the project properties in Visual Studio and finding the "SSL URL" value, e.g. "https://localhost:44300/MyApp".
In this example 44300 is the port number. If yours is different, change that value in the later commands.
Use the following commands in an administrative command prompt (not Powershell):
netsh http delete sslcert ipport=0.0.0.0:44300
netsh http add sslcert ipport=0.0.0.0:44300 certhash=your_cert_hash_with_no_spaces appid=
{123a1111-2222-3333-4444-bbbbcccdddee}
The Guid in the above command can be replaced with one that you generate. It does not correspond to any existing IIS Express value.
For further reference see Handling URL Binding Failures in IIS Express.
With new Chrome 58, nothing from the answers below will help. I've just spent 1 hour uninstalling / reinstalling certificates and trying to find out where the problem is.
Apparently Chrome 58 will refuse certificate because "missing_subjectAltName"
The solution is either "badidea" passphrase or if you need to open popups for login you have to use:
chrome://flags/#allow-insecure-localhost
The source is and the upvote belongs to: https://stackoverflow.com/a/38926117/2089232 :)
I wanted to add this, because it is ridiculous but maybe it will help someone. Keep in mind that I had never opened my project properties before so I have no idea how this happened (I did not change this myself or have the opportunity to), but in Project > Properties > Web my SSL url was listed as my usual URL but as http instead of https (had previously been https because it was working before). I went through all the steps listed on this page, uninstalled VS, then IIS, and finally noticed the error which should have been https://mySSLURL (but was missing the s in https). Once I changed http to https everything worked again.
I just had this issue after updating my VS 2017 to the latest version(s) and created a new (.Net) MVC/WebAPI project (from template). I was able to fix this by adjusting my port numbers to be within the correct range
Chorme Default Port Ranges for DEV SSL
Which I was able to find here: https://www.pluralsight.com/guides/visual-studio-2017-resolving-ssl-tls-connections-problems-with-iis-express
Hope this helps!
You can reinstall IIS Express 10.0 (or whatever version you need) to fix the missing certificate. Download from Microsoft here