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.
Notice: this exact question can be found on the dynamics community forum which as usual isn't exactly responsive...
I can't figure out what's wrong with this environment...
CRM and ADFS are on the same server, different ports:
By browser, navigating to https://myorg.mydomain:444 redirects to https://sts1.mydomain:442 adfs login screen shows up, I input credentials, then I'm redirected back to CRM, everything works perfectly no matter which organization I navigate to. The SSL certificate is a wildcard one, covering *.mydomain (again, no issues whatsoever). Outlook client also works without a hitch.
My issue is, the registration tool (I'm using the one from the 2016 SDK, but this also happens with the 2013 SDK's one ) doesn't seem to be able to connect.
The exception message showing up in the log is (I'm translating from my native language to english, messages might not be 100% accurate)
[Top] Unable to establish a trust relationship for the SSL/TLS secure channel with authority 'sts1.mydomain'
[Inner level 1] Underlying connection closed: <same as above>
[Inner level 2] The remote certificate wasn't deemed valid from the validation procedure
Nothing in particular stands out in the Event Viewer... What's wrong ?
Just before writing this, I also tried the 2011 Registration Tool and it spits out a different error: it attempts to login to ADFS through HTTP instead of HTTPS (it complains about not finding http://sts1.mydomain:442 which doesn't exist).
I also tried importing the aforementioned SSL cert into my trusted root cert authorities, it doesn't seem to matter (everything stays the same).
Update: I forgot to show the connection settings:
(o) On-Premises ( ) Office 365
Server: myorg.mydomain
PORT: 444 [X] Use SSL
Authentication Source: IFD
Username: DOMAIN\USERNAME
Password: PASSWORD
Domain: <BLANK>
[X] Display list
I haven't started fiddling with plugins in 2016 so I'm not sure how that works and which endpoint it's using but I'd try the 2011 plugin registration tool too. It's what I've been using up until now and I think it is a better one than the 2013 and later since you can have multiple servers setup in it.
Regards
When I try to install an extension I get this error:
unable to verify the first certificate
I already know that the problem is our internal network structure, which wraps every SSL Certificate with our own and not every application trusts our certificate.
Is it possible to set the property Trust all SSL certificates in Visual Studio Code?
Thanks
Had the same problem.
Adding environment variable
NODE_TLS_REJECT_UNAUTHORIZED=0
fixed it.
Took this answer from here:
Ignore invalid self-signed ssl certificate in node.js with https.request?
My solution was to add the following to user settings ( File -> Preferences -> User Settings)
"http.proxyStrictSSL": false
I'm trying to sign a Windows 8 appx package with a pfx file I have. I'm using a command like so:
signtool.exe sign /fd sha256 /f "key.pfx" "app.appx"
And from this, I get:
SignTool Error: No certificates were found that met all the given criteria.
What "criteria" am I not meeting? This is only for testing so these are self-signed certificates. I've tried importing the key and then signing it, but it always results in the same error. How do I fix this?
When getting this error through Visual Studio it was because there was a signing certificate setup to match the computer it was originally developed on.
You can check this by going to the project properties > signing tab and checking the certificate details.
You can uncheck "Sign the ClickOnce manifests" to disable signing.
If you don't want to turn this option off you will have to install the certificate.
Try with /debug.1,2 As in :
signtool sign /debug /f mypfxfile.pfx /p <password> (mydllexectuable).exe
It will help you find out what is going on. You should get output like this:
The following certificates were considered:
Issued to: <issuer>
Issued by: <certificate authority> Class 2 Primary Intermediate Server CA
Expires: Sun Mar 01 14:18:23 2015
SHA1 hash: DD0000000000000000000000000000000000D93E
Issued to: <certificate authority> Certification Authority
Issued by: <certificate authority> Certification Authority
Expires: Wed Sep 17 12:46:36 2036
SHA1 hash: 3E0000000000000000000000000000000000000F
After EKU filter, 2 certs were left.
After expiry filter, 2 certs were left.
After Private Key filter, 0 certs were left.
SignTool Error: No certificates were found that met all the given criteria.
You can see what filter is causing your certificate to not work, or if no certificates were considered.
I changed the hashes and other info, but you should get the idea.
1 Please note: signtool is particular about where the /debug option is placed. It needs to go after the sign statement.
2 Also note: the /debug option only works with some versions of signtool. The WDK version has the option, whereas the Windows SDK version does not.
I got the same problem in my console application development and as a quick workaround,
go to project properties then,
click on signing tab and uncheck "Sign the ClickOnce Manifest".
Image Description:
FYI You can also see this less one minute video solution. The above picture is taken form the video.
Please always check your certificate expiry date first because most of the certificates have an expiry date. In my case certificate has expired and I was trying to build project.
If you do not have to sign the app, right click on your project
Project Properties -> Signing -> uncheck "Sign the ClickOnce Manifest"
Also as this MS article suggests,
If you are using Visual Studio 2008 and are targeting .NET 3.5 and using automatic updates, you can just change the certificate and deploy a new version,
In my case I have the wrong type of certificate that I am trying to associate. I had "Server Authentication" rather than "Code signing".
You should be able to see this in Certificate snap in the Intended Purpose section. After that, it just work fine.
Got the same issue, turned out that the private key to the certificate had no permission.
To fix - open the certifacte management, find your certificate, right click -> Manage Private Keys and then in security on top be sure that your user is added and given permissions, that fixed it for me.
In case anyone else runs into this: My problem ended up being that I needed to run the command prompt as administrator before using the signtool.exe app. Then everything works wonderfully.
just uncheck the 'Sign the click once manifests' from the signing tab in project properties,it will remove the error and you can create a new one as from there.
I had this problem and I'm not entirely sure which step below made it work, but hope this helps somebody else...this is what I did:
Install the downloaded certificate (.crt) into certificates (I put it into “personal” store) - right click on .crt file and click Install Certificate.
Run certmgr.msc and export the certificate (found in whichever store you used in the 1st step) as a pfx file including private key and extended properties
Use the exported .pfx file when signing your project
Example signtool: signtool sign /f "c:\mycert.pfx" /p mypassword /d "description" /t http://timestamp.verisign.com/scripts/timstamp.dll $(TargetPath)
where the password is the same as provided during Export
I solved this by using the /sm flag to specify to look in the machine store instead of the default, which is My (Local User) store. Also, it can help to turn on debug for signtool by using /debug.
I'm having the same problem, reading some answers (posted here), I saw my certificate expired.
Just create a new one from my start project. Then at certificates manager deleted the expired certificate.
Now everything compiles fine.
The criteria include account name (whose private key it is associated with), domain, company, expiration date, intended purposes, among other things.
There are many different possible reasons for this error to occur, some have been listed already. Here is another tip: When importing a certificate, be sure you work with the original file received from the certificate authority (CA), or else some of the properties might be lost.
Example: recently I tried to import a certificate exported from a different account on the same machine. The certificate became visible to my account but was not associated with my account, and as a result signtool refused to recognize it without explicitly providing the file name and a password. Which, when done as part of the build process and written out explicitly in a batch file or source file, may not be sufficiently secure. (Importing the original CA-issued certificate solved it.)
I had the same "After Private Key filter, 0 certs were left" message and spent too much of my life trying to figure out what the message meant.
The problem was that I had installed the certificate incorrectly in the Windows Certificate store so there was no private key associated with the code signing certificate.
What I should have done was this:
Using either Firefox or Internet Explorer, submit the
request to the issuer. This generates a PRIVATE KEY which is stored silently by the browser (a dialog appears for a fraction of a second in Firefox). Note that other browsers may not work: your life is too short to find out if they do.
Submit the request, jump through the issuer's validation hoops and loops, sacrifice a goat, pray to the gods, submit a signed statement from your great grandparents, etc.
Download the certificate (.crt) and import it into the same browser. The browser now has both the private key and the certificate.
Export the certificate from the browser as a Personal Information Exchange (.p12) file. You will be asked to supply a password to protect this file.
Keep a backup copy of the .p12 file.
Run the Certificate Manager (certmgr.msc), right click on the Personal certificate store, select All Tasks/Import... and import the .p12 file into Windows. You will be asked for the password you used to protect the file. At this point, depending upon your security requirements, you can mark the key as exportable so you can restore a copy from the Windows store. You can also mark that a password is required before use if you want to break batch scripts.
Run signtool successfully, breathe a sigh of relief, and ponder how much of your life you have wasted due to bad error messages and poor or missing documentation.
My problem ended up being that I did not understand the signtool options. I had provided the /n option with something that did not match my certificate. When I removed that it stopped complaining.
I have had this issue too, tried a lot. Used SDK as well as Visual Studio signing, but everywhere I got "No certificates were found that met all the given criteria".
Solution:
Be aware that, if "after private key filter": '0 left' shows up with option signtool sign /debug..., the cause is your PC doesn't has the CA itself in the store. To solve this, install the CA first (in my case a .crt file), then run the sign again. It should work right now!
Signtool only can be used with a CA which is requested ánd owned by the same PC.
I had a similar problem my computer name had change and the certificate had expired. I was able to resolve this issue by creating a new test certificate.
In Visual Studio, right click on project in solution explorer. Select properties. Select Signing in properties window. Click "Create Test Certificate....". Enter password information for test certificate and click ok.
With /debug, when you get this message "After Private Key filter, 0 certs were left.", one reason could be that the pfx file doesn't have the private key.
When you export the installed certificate to pfx file ensure to enable the check box to also include the private key.
Go to project properties and uncheck all fields from the Firm before init the compilation
The digicert Token I use, must be recognized as "Microsoft Usbccid-Smartcard-Leser(WUDF)".
In case not, I get this error message 'No certificates were found that met all given criteria ...'.
That kept me searching in SignTool options and the properties of the certificates quite long with no effort at all. So I hope it helps someone :-)
I got this error when using Git Bash.
Using PowerShell succeeded.
If it helps anyone.