I have the error "The X.509 certificate ... chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. The revocation function was unable to check revocation because the revocation server was offline."
I get this error when I run my wcf service in IIS with an apppool under the "ApplicationPoolIdentity". I have given the "ApplicationPoolIdentity" accounts (iis apppool*) private key access permissions to the certificates in the store. It works fine under "Network Service". The certificate is internally issued from one of our domain controllers. I thought that Microsoft wants websites to be run under "ApplicationPoolIdentity" now. Is there a way to give the correct permissions to the "ApplicationPoolIdentity" in order to avoid this error or should I just use "Network Service" instead?
What you will probably notice when you put a network sniffer like WireShark on the line, is that the identity that your application pool is running under is not allowed to go to the location mentioned as URL in the revocation parameter in your certificate chain. That problem does not occur when the application pool is running under the NETWORK service account, as you describe.
As stated by the error logged to you, you can also change the revocationMode="NoCheck" to disable WCF checking for revoked certificates. Read http://msdn.microsoft.com/en-us/library/aa347699.aspx for details. But you should only do that either is a safe closed environment or for development purposes.
Related
Here's my setup
an IdentityServer 4 as a stateless reliable ASP.NET Core service.
a WebAPI as a reliable ASP.NET Core service.
using them with a JS client, it is now working with HTTP. The problem is with HTTPS. The WebAPI needs to request the openID config via htttps [is4URL].well-known/openid-configuration. I'm getting this error
System.InvalidOperationException: IDX10803: Unable to obtain
configuration from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.IO.IOException: IDX10804: Unable to retrieve document from:
'https://localhost:9999/.well-known/openid-configuration'. --->
System.Net.Http.HttpRequestException: An error occurred while sending
the request. ---> System.Net.WebException: The underlying connection
was closed: Could not establish trust relationship for the SSL/TLS
secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
can anybody help me to make this work in localhost with the SF Local Cluster Manager?
Thanks
Here's my two cents worth but it will need to be verified...
I am assuming that you have created a self-signed certificate using following article or similar but the certificate has same properties.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure-ssl-certificate
This means that the certificate can not be verified via actual CA. Ofcourse with self-signed certificate this is not possible.
Now when you upload the certificate to Azure App Service it installs in CurrentUser - MyStore. With self-signed certificate, it also needs to be installed in LocalMachine Root store.
This is becouse then the machine's Certificate Authority can verify that certificate to be valid. (May be a security expert can correct me if I am wrong but thats my theory). I have got same setup on my locally hosted windows server where the self-signed certificate is installed in Root Certificate Store as well as Personal store and the app works. This is the reason I belive this happens.
So this part which needs to be verified. Following is the article which shows you how you can do this in Azure App service.
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-configure-ssl-certificate-portal
AGAIN THIS IS JUST A THEORY THIS NEEDS TO BE VERIFIED. :)
EDIT:
I have just tested this and it is the case. In cloud services you can do as shown in second link above and create Web Job which install certificate in appropriate store.
For Azure App Service unfortunaltly you dont have access to root store. It has to be install in CurrentUser's personal store. Which means the self signed certificate will not work, and you have to purchase a real certificate. :( I think this is a real thumb down to Microsoft. Why should I need to pay for real certificate for my dev/test environment? (Rant Over)
For Service Fabric you will need to find out how to install certificate in Root Store as well as personal store (if thats possible at all). Here's Links that might be useful
http://ronaldwildenberg.com/running-an-azure-service-fabric-cluster-locally-on-ssl/
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-update-certs-azure
Hope this helps.
We've an ASP.NET MVC4 app where there is a part which should be secured through client certificates.
When anyone wants to connect to this part of the app, browsers should ask them for a client certificate, once they select it, our server will get it, check it's validity and show the content.
Ok, I'm getting trouble with the select certificate part. Before setting it just to one folder on views content, I'm trying to configure this on the global app.
I've set SSL to be required, and also set require client certificates on SSL Configuration on apps configuration on IIS.
I've enabled the iisClientCertificateMappingAuthentication (although I've set no mapping yet)
When I try to access the app both, Firefox and Chrome, return a 403 forbidden error, stating that I have no access to the app with the credentials provided.
I've a client certificate installed on my local machine and the CA who created this certificate as a trusted root certificate on server local machine.
I'm not being prompted for certificate.
If I uncheck the "require" from client certificates on SSL Settings, I can access the app through https.
This is the first time I work with client certificates, so it's being a bit confusing and maybe I'm not giving enough info. Feel fre to ask for further info on the comments.
EDIT: I've exported the client certificate, copied it to the server and checked it there. The certificate shows as valid and every element in the certification chain seems to be recognized in the server.
I've checked IIS logs also, and the error I'm getting is 403.7, so the certificate is not being issued to the server or it's invalid.
Now... I've checked that the certificate is valid on the server, it's correctly installed on the client but it's not getting to the server or is not beign validated there... what am I missing here?
Ok, finally I've found the problem, it's related to the buffer size reserved for the list of trusted certification authorities.
Check this kb article:
https://support.microsoft.com/en-us/kb/933430
TL DR; To solve the problem just add a new entry in the registry at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
named SendTrustedIssuerList as a DWORD value with value 0.
This way, the server won't send the trusted certification authorities list, so browsers will display the complete list of certificates to the user.
I have my WCF service running in HTTP. I want to make my service run in HTTPS. I did this in my local with self seigned certificate and its working fine. But I'm getting
"Could not establish trust relationship for the SSL/TLS secure channel with authority"
error when I deployed my code in QA environment and created Self signed certificate for the same. I found some solution to validate the certificate at client side (Link). But I'm looking for some solution to fix this from server side. I don't want to disturb the client.
I suspect the error reflect that the client does not recognize your self-signed certificate or the underlying certificate authority. As such, until the client adds the client certificate to their certificate store or otherwise trusts the certificate, the only way they will be able to access the service is via a validation workaround like the one reflected in the link you included.
In order to determine the underlying cause of the issue, you may want to enable WCF Tracing and review the exceptions (especially inner exceptions).
My team supports many WCF connections protected by mutual certificate authentication. We have noticed that the error top level error may not provide as much information as the inner exception. Just yesterday, I had a site with that exact error. When we looked in the trace file, we saw an inner exception revealing that the certificate had not been deployed to the certificate store in the proper location. A few days previously, the “could not establish trust relationship” error had an underlying inner exception that revealed the certificate had been revoked by the certificate authority.
Hope this helps.
Regards,
I am trying to resolve a problem whereby trying to set a users password over LDAP is failing because of an access denied error - even though I am authenticating against the AD with an admin user.
An answer found in stackoverflow says that either I have to run the IIS user as the admin user (which does work) or i should connect to LDAP via SSL.
I cant go with the first option because I am using Elastic Beanstalk which will create and terminate instances so i cant change/set the user that IIS will be running as. So I am trying to use the LDAP over SSL idea.
My question is does that still require that the client itself also have a certificate installed in order to establish trust with the Domain controller? Or does this work just by installing a cert on the Domain controller and allowing the connection over SSL?
If it requires a certificate on the client then I have the same problem as i cant install anything on the client server other than the deployed app since Beanstalk is going to recereate and terminate that instance at will.
So does LDAPS require a cert on the client?
Is there a better way to solve my problem given the infrastructure i am using?
So does LDAPS require a cert on the client?
no, LDAPS do not require client certificate. Domain controller certificate is sufficient to utilize LDAPS. More details about LDAPS and certificate requirement: LDAP over SSL (LDAPS) Certificate
trying to set a users password over LDAP is failing because of an access denied error
there might be over9000 reasons why you receive this message. You need to check whether you are successfully authenticated on DC, if yes, check whether you have permissions and privileges (especially, if UAC is enabled). I would set up audit policies (on failed user password changes) and check Security eventlog to figure out what is going wrong.
No.
For openldap, I achieved this by adding this line to ldap.conf. But be aware of that, when you do that, your connections will be open to attacks like man-in-the-middle or any other.
TLS_REQCERT never
This is what I found using trial and error approach:
Actually, LDAPS server always asks for client certificate. You can verify that by turning on SCHANNEL log and observing the following message:
If there is no client authentication certificate than LDAPS connection still succeeds, i.e. no client authentication certificate is required indeed. But if you have some invalid client authentication certificate (in my case it was an expired cert installed long ago by a third party app) the connection will fail w/o any error or warning in SCHANNEL log on the client side. It took me a while to figure this out.
Yes of corse your client need a certificate to allow ladps communication betwen
him and de server.
According to
windowsitpro.com:
As an option, you can use LDAPS for client authentication -- but doing so requires that you also install a client authentication certificate on each of your clients."
We have a wcf client, which calls an external webservice. The service is accessed over SSL. The certificate is not a self signed cert. It is issued by Verisign.
The client is hosted in IIS 6 and the application pool's identity is a domain service user.
Every time we want our client to access the remote service we get the following well known exception: "Could not establish trust relationship for the SSL/TLS secure channel with authority-.."
It turned out, that once you access the URL with IE on the same server, our WCF client is working as expected and the certificate is accepted!
My conclusion is, that the URL accessed with IE modified the server in a way, that our WCF client is able to do the validation afterwards. What is our WCF client missing?
(I'm aware that one can circumvent certificate validation by returning true in the ServerCertificateValidationCallback, but this is not an option for production.)
Considering the situation as described, I suspect that your IIS hosted client is not able to load the Verisign root certificate. And it is always a bit unclear to me under which account such IIS based client is trying to access the certificate store. It might be your domain service account user, it might be the ASP.NET user, it might be some other system defined account. This often causing the error.
When you browse the service with IE, there is no doubt about the user (your own credentials) being able to load the Verisign root certificate and resolve the trust relationship correctly.
Please:
Make sure the Verisign root certificate in in the Trusted Root Authorities store under the Local Computer Account
Have your app.config of your client refer to the correct root certificate to be loaded from the correct store.
You might want to run ProcessMonitor to find out which user is trying to load the certificate from the store.