I have an .NET 6 application needing to identify and extract the different certificates from a "child" (client) pfx file. The pfx file contains the root ca certificate and also the child (client) certificate. The certificates from the pfx file are iterated using the X509Certificate2Collection object:
var clientCertPfxFilePath = "xxx.pfx";
var certPw = "...";
X509Certificate2Collection certCollection = new X509Certificate2Collection();
certCollection.Import(clientCertPfxFilePath, certPw, X509KeyStorageFlags.PersistKeySet);
foreach (X509Certificate2 cert in certCollection)
{
// Check if "cert" is root ca certificate - how?
}
Alternatively the certificates can be iterated using the X509Chain object
var clientCertificate = new X509Certificate2(clientCertPfxFilePath, certPw);
X509Chain certChain = new X509Chain();
certChain.Build(clientCertificate);
foreach (var element in certChain.ChainElements)
{
// Check if "element" is root ca certificate - how?
}
I am looking for a solution how to programmatically identify which from the iterated certificates is the root ca certificate, with either one of the both above code snippets
For X509Chain the answer is easy... if chain.Build returned true then the chain ends in a trusted element, and therefore the last element will be a trusted root certificate. (If you are reading this in the far future then maybe X509Chain will have been enhanced to trust non-root anchors, but that would almost certainly require a different call pattern than was presented here.)
For certificates, detecting a self-signed certificate is hard, but you can check if a certificate is self-issued fairly easily:
bool selfIssued = cert.SubjectName.RawData.SequenceEquals(cert.IssuerName.RawData);
(That is, a self-issued certificate is one whose subject name and issuer name are encoded identically.)
A self-signed certificate is a self-issued certificate whose public key can validate the signature on the certificate. The signature verification isn't exposed through .NET, so it's hard to check, but many applications assume that self-issued and self-signed are the same anyways, so you can, too.
#bartonjs Unfortunately the solution with chain.Build does not work on a computer where no certificates were installed in the windows certificate store. The root ca certificate is available in the certificate chain after calling "chain.Build" only on the computers where the root ca is installed in the certificate store. On these computers the certificate chain has 2 elements, the client certificate and the root ca certificate. On the computers having no root ca installed in the certificate store the chain contains only 1 element after the "chain.Build" call (the client certificate). The root ca does not appear anymore, although using absolutely the same pfx file!
We have a c# app which comunicates with devices. By now we just install the certifciates in the windows store.
Now we want a behaviour like the "windows remote desktop". Once the we connect to the device we get the (self signed) certificate. Then we ask the user if he trust the certificate. This is quite easy with SslStream.
Initialize SSL stream:
SslStream sslStream = new SslStream(.GetStream(), false, new RemoteCertificateValidationCallback(ValidateServerCertificate), null);
Handler:
static bool ValidateServerCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
if (sslPolicyErrors != SslPolicyErrors.None)
{
string certificateHash = CreateHash(certificate);
//pseudo code -> go to database and check if the certificate is already trusted
if(database.TrustedCertificates.Contains(certificateHash))
{
return true;
}
//TODO ask for permission
bool isTrusted = true;
if (isTrusted)
{
//TODO add certificate (hash) to store
database.TrustedCertificates.Add(certificateHash);
}
}
return true;
}
We do not want to add the manually trusted certificates in the windows built in store. Instead we would have our very own certificate store in our database. Therefor the trusted certificate would only be valid for our application.
Now I'm wondering if it's best practice to store the trusted certificates in a own store rather than to add them to the windows certificate store (certlm.msc). Is it save enough to store them in the app's database (just make a table TrustedCertificates)? Do the certificates need to be hashed like passwords? Should this be avoided in any case and only use the windows certificate store?
Any thoughts?
I got one Digital certificate from NeutralUS CA. I have installed in my local system. I found the installed certificate under Personal Certificates in MMC and my application validated with this certificate. I just moved to my application to our production server and installed same certificate. here also i can see my certificate under personal certificates in MMC on windows server 2008 R2. But when I am trying to load certificate with serial number, it is showing the store certificates count is zero. Could you please tell me what would be the reason? Why it is not recognize from the Personal folder. i have only one certificate in in personal folder.
var clientCertStore = new X509Store(StoreName.My, StoreLocation.CurrentUser);
clientCertStore.Open(OpenFlags.OpenExistingOnly & OpenFlags.ReadOnly);
base.Data.ErrorLog.Append("Certificates Count : " + clientCertStore.Certificates.Count);
I just log the data into one text file... it is giving clientCertStore.Certificates.Count as 0.
I got one Digital certificate from NeutralUS CA. I have installed in my local system.
What is installed? Is the end entity cert installed and trusted? Or is it the NeutralUS CA?
I could not find the NeutralUS CA for download on the net. That's unusual.
Could you please tell me what would be the reason? Why it is not recognize from the Personal folder.
I suspect its a problem with accounts (but its just a guess). What account was the certificate installed under, and what account is the program running under?
I really despise how difficult Java and .Net make it to use a damn certificate. Here's the code I use to avoid wasting time with those damn stores. It allows you to load directly from the filesystem or an app bundle. It also does not use the hundreds of CAs and subordinates that Windows carries around.
static bool VerifyServerCertificate(object sender, X509Certificate certificate,
X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
try
{
String CA_FILE = "ca-cert.der";
X509Certificate2 ca = new X509Certificate2();
ca.Import(CA_FILE);
X509Chain chain2 = new X509Chain();
chain2.ChainPolicy.ExtraStore.Add(ca);
// Check all properties
chain2.ChainPolicy.VerificationFlags = X509VerificationFlags.NoFlag;
// This setup does not have revocation information
chain2.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;
// Are there any failures from building the chain?
chain2.Build(new X509Certificate2(certificate));
if (chain2.ChainStatus.Length == 0)
return true;
// Verify the status is NoError
bool result = chain2.ChainStatus[0].Status == X509ChainStatusFlags.NoError;
Debug.Assert(result == true);
return result;
}
catch (Exception ex)
{
Console.WriteLine(ex);
}
return false;
}
And I still have not figured out how to set the original X509Chain chain that comes in as a parameter to the X509Chain chain2 that I want to use before the callback VerifyServerCertificate is invoked.
I'm lost in a twisty maze of certificates and private keys.
I am writing a server in C#. I want it to accept SSL connections. For test purposes, I want to generate a certificate for "localhost", and use that certificate for the server. Ideally I don't want to pollute my certificate store, so I just want a file, or files, on disk that the C# code can load to provide the certificate.
Everything I have tried (using cookbook approaches suggested by web searches) either gives me "The credentials supplied to the package were not recognized" or "The server mode SSL must use a certificate with the associated private key."
Is there a way to generate a certificate and private key, and subsequently to load them into an X509Certificate object without also loading them into my machine certificate store?
In the end, I ran the following to create a server.pfx file:
makecert.exe -r -pe -n "CN=localhost" -sky exchange -sv server.pvk server.cer
pvk2pfx -pvk server.pvk -spc server.cer -pfx server.pfx
Then I loaded it in code with:
certificate = new X509Certificate2("server.pfx", "password");
(I didn't actually hard code the password like that :-)
The trick was to know that I needed a pfx file, and that I needed to load it using the X509Certificate2 class, rather than X509Certificate.
Niki Loche method works.
If you get The specified network password is not correct., then you should try it without password in C#. It doesn't matter what your input password was in makecert.
certificate = new X509Certificate2("Server.pfx", "");
But if you want to use password (there is a reason, it's there :)), try changing pvk2pfx.exe command to:
pvk2pfx.exe" -pi password -pvk Server.pvk -spc Server.cer -pfx Server.pfx
and in C# enter:
certificate = new X509Certificate2("Server.pfx", "password");
Password must be the same as it is in creating cer file.
That did the trick for me. I hope it will help someone.
There are a number of tools that should let you act as your own CA and generate a certificate. XCA is one of them. There are also a number of methods using OpenSSL commands, for example.
Generating a self-signed certificate only may seem like the easiest option, but using a test CA (and a separate server certificate) may be worth it. This would allow you to import the test CA into the browser's store if needed to make the tests more realistic. It's not much more difficult with the right tools (e.g. XCA).
Once you have generated your server certificate and its private key, turn it into a PKCS#12 file (.p12/.pfx).
You should then be able to load it using X509Certificate2.import(...). (See example in this answer.)
I recently developed a SMTP server with TLS. I needed to install the server as a Windows Service on a Windows Server 2012 box. I used a Let's Encrypt SSL Certificate (* wildcard) for my domain. While developing "on the server" I had to run Visual Studio as Administrator for my code to work using "new X509Certificate("cert.pfx", "{password}") and it ran perfectly. However, once installed as a service, that scheme did not work. Turns out the simpler/safer way is to use X509Store. Here's the code that solved the problem...
private X509Certificate GetSslCertificate()
{
X509Certificate cert = null;
string certname = "*.mydomain.com";
try
{
X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly);
foreach (X509Certificate certificate in store.Certificates)
{
if (certificate.Subject.ToLower().Contains(certname))
{
cert = certificate;
break;
}
}
}
catch (Exception) { /* Handle Exception */ }
return cert;
}
Also notice I used "LocalMachine" as the StoreLocation. You'll need to change to CurrentUser if that's where you installed your SSL Certificate.
If you have IIS, you can do it through the IIS Manager as detailed here:
http://blogs.msdn.com/b/ericnel/archive/2009/09/22/using-iis-to-generate-a-x509-certificate-for-use-with-the-windows-azure-service-management-api-step-by-step.aspx
I had the same issue when importing a machine certificate from the machine store (not the user store). I solved it by running Visual Studio as an administrator, as administrator privileges are required to access the private key of a machine store certificate.
I have a simple web service call, generated by a .NET (C#) 2.0 Windows app, via the web service proxy generated by Visual Studio, for a web service also written in C# (2.0). This has worked for several years, and continues to do so at the dozen or so places where it is running.
A new installation at a new site is running into a problem. When attempting to invoke the web service, it fails with the message saying:
Could not establish a trust relationship for the SSL/TLS secure
channel
The URL of the web service uses SSL (https://) -- but this has been working for a long time (and continues to do so) from many other locations.
Where do I look? Could this be a security issue between Windows and .NET that is unique to this install? If so, where do I set up trust relationships? I'm lost!
The following snippets will fix the case where there is something wrong with the SSL certificate on the server you are calling. For example, it may be self-signed or the host name between the certificate and the server may not match.
This is dangerous if you are calling a server outside of your direct control, since you can no longer be as sure that you are talking to the server you think you're connected to. However, if you are dealing with internal servers and getting a "correct" certificate is not practical, use the following to tell the web service to ignore the certificate problems and bravely soldier on.
The first two use lambda expressions, the third uses regular code. The first accepts any certificate. The last two at least check that the host name in the certificate is the one you expect.
... hope you find it helpful
//Trust all certificates
System.Net.ServicePointManager.ServerCertificateValidationCallback =
((sender, certificate, chain, sslPolicyErrors) => true);
// trust sender
System.Net.ServicePointManager.ServerCertificateValidationCallback
= ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));
// validate cert by calling a function
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);
// callback used to validate the certificate in an SSL conversation
private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
bool result = cert.Subject.Contains("YourServerName");
return result;
}
The very simple "catch all" solution is this:
System.Net.ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
The solution from sebastian-castaldi is a bit more detailed.
Thoughts (based on pain in the past):
do you have DNS and line-of-sight to the server?
are you using the correct name from the certificate?
is the certificate still valid?
is a badly configured load balancer messing things up?
does the new server machine have the clock set correctly (i.e. so that the UTC time is correct [ignore local time, it is largely irrelevent]) - this certainly matters for WCF, so may impact regular SOAP?
is there a certificate trust chain issue? if you browse from the server to the soap service, can you get SSL?
related to the above - has the certificate been installed to the correct location? (you may need a copy in Trusted Root Certification Authorities)
is the server's machine-level proxy set correctly? (which different to the user's proxy); see proxycfg for XP / 2003 (not sure about Vista etc)
I personally like the following solution the most:
using System.Security.Cryptography.X509Certificates;
using System.Net.Security;
... then before you do request getting the error, do the following
System.Net.ServicePointManager.ServerCertificateValidationCallback = delegate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) { return true; };
Found this after consulting Luke's Solution
If you do not wan't to blindly trust everybody and make a trust exception only for certain hosts the following solution is more appropriate.
public static class Ssl
{
private static readonly string[] TrustedHosts = new[] {
"host1.domain.com",
"host2.domain.com"
};
public static void EnableTrustedHosts()
{
ServicePointManager.ServerCertificateValidationCallback =
(sender, certificate, chain, errors) =>
{
if (errors == SslPolicyErrors.None)
{
return true;
}
var request = sender as HttpWebRequest;
if (request != null)
{
return TrustedHosts.Contains(request.RequestUri.Host);
}
return false;
};
}
}
Then just call Ssl.EnableTrustedHosts when your app starts.
If you are using Windows 2003, you can try this:
Open Microsoft Management Console
(Start --> Run --> mmc.exe);
Choose File --> Add/Remove Snap-in;
In the Standalone tab, choose Add;
Choose the Certificates snap-in, and
click Add;
In the wizard, choose the Computer
Account, and then choose Local
Computer. Press Finish to end the
wizard;
Close the Add/Remove Snap-in dialog;
Navigate to Certificates (Local
Computer) and choose a store to
import:
If you have the Root CA certificate
for the company that issued the
certificate, choose Trusted Root
Certification Authorities;
If you have the certificate for the
server itself, choose Other People
Right-click the store and choose All
Tasks --> Import
Follow the wizard and provide the
certificate file you have;
After that, simply restart IIS and try
calling the web service again.
Reference: http://www.outsystems.com/NetworkForums/ViewTopic.aspx?Topic=Web-Services:-Could-not-establish-trust-relationship-for-the-SSL/TLS-...
Luke wrote a pretty good article about this ..
pretty straight forward .. give this a try
Luke's Solution
Reason (quote from his article (minus cursing))
"..
The problem with the code above is that it doesn’t work if your certificate is not valid. Why would I be posting to a web page with and invalid SSL certificate? Because I’m cheap and I didn’t feel like paying Verisign or one of the other **-*s for a cert to my test box so I self signed it. When I sent the request I got a lovely exception thrown at me:
System.Net.WebException
The underlying connection was closed. Could not establish trust relationship with remote server.
I don’t know about you, but to me that exception looked like something that would be caused by a silly mistake in my code that was causing the POST to fail. So I kept searching, and tweaking and doing all kinds of weird things. Only after I googled the ***n thing I found out that the default behavior after encountering an invalid SSL cert is to throw this very exception.
.."
Microsoft's SSL Diagnostics Tool may be able to help identify the issue.
UPDATE the link has been fixed now.
add this:
ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;}
right before the line that you're calling the service
I just encountered this issue. My resolution was to update the system time by manually syncing to the time servers. To do this you can:
Right-click the clock in the task bar
Select Adjust Date/Time
Select the Internet Time tab
Click Change Settings
Select Update Now
In my case this was syncing incorrectly so I had to click it several times before it updated correctly. If it continues to update incorrectly you can even try using a different time server from the server drop-down.
Try this:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
Notice that you have to work at least with 4.5 .NET framework
I had a similar problem in .NET app in Internet Explorer.
I solved the problem adding the certificate (VeriSign Class 3 certificate in my case) to trusted editors certificates.
Go to Internet Options-> Content -> Publishers and import it
You can get the certificate if you export it from:
Internet Options-> Content -> Certificates -> Intermediate Certification Authorities -> VeriSign Class 3 Public Primary Certification Authority - G5
thanks
I had this error running against a webserver with url like:
a.b.domain.com
but there was no certificate for it, so I got a DNS called
a_b.domain.com
Just putting hint to this solution here since this came up top in google.
For those who are having this issue through a VS client side once successfully added a service reference and trying to execute the first call got this exception:
“The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel”
If you are using (like my case) an endpoint URL with the IP address and got this exception, then you should probably need to re-add the service reference doing this steps:
Open the endpoint URL on Internet Explorer.
Click on the certificate error (red icon in address bar)
Click on View certificates.
Grab the issued to: "name" and replace the IP address or whatever name we were using and getting the error for this "name".
Try again :).
Thanks
In my case I was trying to test SSL in my Visual Studio environment using IIS 7.
This is what I ended up doing to get it to work:
Under my site in the 'Bindings...' section on the right in IIS, I had to add the 'https' binding to port 443 and select "IIS Express Developement Certificate".
Under my site in the 'Advanced Settings...' section on the right I had to change the 'Enabled Protocols' from "http" to "https".
Under the 'SSL Settings' icon I selected 'Accept' for client certificates.
Then I had to recycle the app pool.
I also had to import the local host certificate into my personal store using mmc.exe.
My web.config file was already configured correctly, so after I got all the above sorted out, I was able to continue my testing.
My solution (VB.Net, the "staging" (UAT) version of this application needs to work with the "staging" certificate but not affect requests once they are on the live site):
...
Dim url As String = ConfigurationManager.AppSettings("APIURL") & "token"
If url.ToLower().Contains("staging") Then
System.Net.ServicePointManager.ServerCertificateValidationCallback = AddressOf AcceptAllCertifications
End If
...
Private Function AcceptAllCertifications(ByVal sender As Object, ByVal certification As System.Security.Cryptography.X509Certificates.X509Certificate, ByVal chain As System.Security.Cryptography.X509Certificates.X509Chain, ByVal sslPolicyErrors As System.Net.Security.SslPolicyErrors) As Boolean
Return True
End Function
A variation I've been using for a while it if helps anyone.
The caller has to explicitly request that untrusted certifications are required and places the callback back into it's default state upon completion.
/// <summary>
/// Helper method for returning the content of an external webpage
/// </summary>
/// <param name="url">URL to get</param>
/// <param name="allowUntrustedCertificates">Flags whether to trust untrusted or self-signed certificates</param>
/// <returns>HTML of the webpage</returns>
public static string HttpGet(string url, bool allowUntrustedCertificates = false) {
var oldCallback = ServicePointManager.ServerCertificateValidationCallback;
string webPage = "";
try {
WebRequest req = WebRequest.Create(url);
if (allowUntrustedCertificates) {
// so we can query self-signed certificates
ServicePointManager.ServerCertificateValidationCallback =
((sender, certification, chain, sslPolicyErrors) => true);
}
WebResponse resp = req.GetResponse();
using (StreamReader sr = new StreamReader(resp.GetResponseStream())) {
webPage = sr.ReadToEnd().Trim();
sr.Close();
}
return webPage;
}
catch {
// if the remote site fails to response (or we have no connection)
return null;
}
finally {
ServicePointManager.ServerCertificateValidationCallback = oldCallback;
}
}
If not work bad sertificate, when ServerCertificateValidationCallback return true;
My ServerCertificateValidationCallback code:
ServicePointManager.ServerCertificateValidationCallback += delegate
{
LogWriter.LogInfo("Проверка сертификата отключена, на уровне ServerCertificateValidationCallback");
return true;
};
My code which the prevented execute ServerCertificateValidationCallback:
if (!(ServicePointManager.CertificatePolicy is CertificateValidation))
{
CertificateValidation certValidate = new CertificateValidation();
certValidate.ValidatingError += new CertificateValidation.ValidateCertificateEventHandler(this.OnValidateCertificateError);
ServicePointManager.CertificatePolicy = certValidate;
}
OnValidateCertificateError function:
private void OnValidateCertificateError(object sender, CertificateValidationEventArgs e)
{
string msg = string.Format(Strings.OnValidateCertificateError, e.Request.RequestUri, e.Certificate.GetName(), e.Problem, new Win32Exception(e.Problem).Message);
LogWriter.LogError(msg);
//Message.ShowError(msg);
}
I disabled CertificateValidation code and ServerCertificateValidationCallback running very well