I'm using Windows Server 2012 and IIS 8.5. I've set SSL for the website and the SSL Settings are: Require Required and Require Client Certificates.
The client certificate that I'm sending to the server has been issued by a self-signed authority (let's called it MyCompany CA). MyCompany CA certificate has been successfully installed in the Local Computer Account - Trusted Root Certification Authorities. It's expiration date is 2039, so is the client certificate expiration date.
However, with all this setup, I'm getting an error 403.16 as result. I've enabled Failed Request Tracing Rules and managed to log an erroneous request and got some extra details about it:
52.- MODULE_SET_RESPONSE_ERROR_STATUS - Warning
ModuleName - IIS Web Core
Notification - BEGIN_REQUEST
HttpStatus - 403
HttpReason - Forbidden
HttpSubStatus - 16
ErrorCode - A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. (0x800b0109)
ConfigExceptionInfo
I've checked multiple sites regarding the result 403.16 and error code 0x800b0109 and all of them points to the certification authority not been installed in Local Computer - Trusted Root Certification Authorities, but that's not my case.
Thanks!
I have been working on this for a long time and finally found it!
Add a new key to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Value name: ClientAuthTrustMode
Value type: REG_DWORD
Value data: 2
Refresh the webpage, select the certificate and watch the magic happen.
Research
Using Windows 8 and IIS 8.5 I followed the instructions here http://itq.nl/testing-with-client-certificate-authentication-in-a-development-environment-on-iis-8-5/.
Certificates were created in the correct place and everything configured in IIS properly but I kept getting 403.16 errors.
After the many MSDN articles and other attempts failed I found the following registry setting.
Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Value name: ClientAuthTrustMode
Value type: REG_DWORD
Value data: 2
Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Value name: SendTrustedIssuerList
Value type: REG_DWORD
Value data: 0 (False, or delete this key entirely)
Here is some more information about this specific setting (found here: http://technet.microsoft.com/en-us/library/hh831771.aspx)
Defaults for Trust Modes
There are three Client Authentication Trust Modes supported by the Schannel provider. The trust mode controls how validation of the client’s certificate chain is performed and is a system-wide setting controlled by the REG_DWORD “ClientAuthTrustMode” under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.
0 Machine Trust (default)
Requires that the client certificate is issued by a certificate in the Trusted Issuers list.
1 Exclusive Root Trust
Requires that a client certificate chains to a root certificate contained in the caller-specified trusted issuer store. The certificate must also be issued by an issuer in the Trusted Issuers list
2 Exclusive CA Trust
Requires that a client certificate chain to either an intermediate CA certificate or root certificate in the caller-specified trusted issuer store.
For information about authentication failures due to trusted issuers configuration issues, see Knowledge Base article 280256.
Hope this work for you as well.
I have tried the solution suggested above and it works fine.
An alternative solution which doesn't involve editing the registry:
https://support.microsoft.com/en-us/help/2795828/lync-server-2013-front-end-service-cannot-start-in-windows-server-2012
The main point from this article is to remove all non-signed certificates from the Local Computer Trusted Root folder.
If you use group policies to deploy certificates, make sure that the Trusted Root Certification Authorities store only contains self-signed certificates (certificates in which the certificate property "Subject" is the same as the certificate property "Issuer"). Move any certificates that are not self-signed certificates from the Trusted Root Certification Authorities store to the Intermediate Certification Authorities store.
If you import new certificates manually, make sure that you select the
computer’s Trusted Root Certification Authorities store for the
self-signed certificates, and the computer’s Intermediate
Certification Authorities store for the certificates that are not
self-signed certificates.
You can find all the non-self signed certificates by using the Powershell script:
Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File "c:\computer_filtered.txt"
Move those certs to the Intermediate Certification Authorities folder in mmc.
I had to reboot the server to get the ClientAuthTrustMode setting to apply.
If you use IIS10 on Windows2022, TLS1.3 is turned on by default. Then maybe follwing can answer can help you: https://stackoverflow.com/a/75336463/4994931
Related
I have the company CA signed certificate, intermediate and server certificate in the identity store ( .jks) but still the browser says , cannot be verified by a trusted authority error. Using weblogic -10.3.1 from the weblogic logs i also notice this -
Invalid/unknown SSL header was received from peer x.y.z.12 during SSL handshake
But when I install the root and intermediate certificates into certmgr.msc then when i access the url again in a new window it has no error on the browser and also no error log in the weblogic server.
What could be wrong ?
Global CA's have their root and intermediates recognised by all the modern browsers. However when browser encounter s a certificate whose intermediate and roots aka chain certificates & ca certificates are not a part of its trust store so it fails to chain the leaf certificate to its issuer. So in order to mitigate thi, the roots and intermediates of the company ca must be added so that the browser can verify the complete chain.
Agreed .but thats how the trust works. The company issues ca certificate is known only to your organization but browsers are accessed globally and if you want make the certificate trusted in all the browsers then either you switch to public ca issued certificates or get your root certificate cross signed by a global ca root.
I'm getting the error mentioned in this question:
The X.509 certificate CN=Farm chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust.
What I don't understand why I'm getting this error as the certificate I use for my request to the WCF service is added as shown below:
client.ClientCredentials.Peer.PeerAuthentication.CertificateValidationMode =
X509CertificateValidationMode.ChainTrust;
client.ClientCredentials.ClientCertificate.SetCertificate(
StoreLocation.CurrentUser,
StoreName.My,
X509FindType.FindBySerialNumber,
"MyCertificatesSerialNumber" );
The certificate itself is a self-signed certificate in the store shown above. When I click on it to show the certification path, no errors are shown (the root certificate is also a self-signed certificate). The root certificate was manually imported into the trusted root certification authorities.
From the error message I would have expected that there was an error in the certification chain with one of my certificates, but there isn't. Any ideas?
Update
I'm using Internet Explorer 9 as my browser to access the webservice. Programmatically I'm using a C# console application.
I had exactly the same problem - my own trusted root CA which signed another certificate. No errors were shown in the certificate store.
It turned out that having a trusted root CA and a certificate is not sufficient! You also need a certificate revocation list! Take a look at this MSDN Link.
So simply create such a .crl and add it also to the trusted root certificate authorities and everything works fine!
makecert -crl -n "CN=CARoot" -r -sv CARoot.pvk CARoot.crl
or simply turn of the revocation list check:
...RevocationMode = X509RevocationMode.NoCheck;
I had this problem - this is what I'd suggest:
On the server, make sure that the root cert is located on the "local computer" side of the computer, not "Current User". The other thing is that the SSL cert needs to be derived from the root cert. I eventually got it all to work using a script that included these lines:
rem creates root authority file and cert in localmachine\root and gives it the right to sign certs
makecert.exe -a sha1 -n CN=RootCert RootCertName -sr LocalMachine -ss Root -sky signature -pe -r -sk MyNewKey -cy authority
rem creates ssl cert, puts it in the currentuser\Personal store, signing it based on the root cert
makecert.exe -n cn=HostURL SSLCertName -is root -ic RootCertName -sky exchange -pe -sv SSLCertPrivateKeyName -eku 1.3.6.1.5.5.7.3.1
It's complicated, tedious stuff. You just have to keep at it.
I faced a similar issue while trying to connect to a self hosted WCF service using net.tcp binding. I already had the self signed root CA certificate installed in the CurrentUser certificate store, client was using a certificate signed by the root CA cert.
Installing the root CA certificate in LocalComputer certificate store fixed the error "A certificate chain could not be built to a trusted root authority". My WCF Server process runs using current user account hence this step was not obvious.
The next error was "The revocation function was unable to check revocation for the certificate"
To fix this, I created an empty Certificate Revocation List for the root CA cert and then installed the CRL in the LocalComputer certificate store. (Please check this link for details : https://msdn.microsoft.com/en-us/library/ff648732.aspx)
I also set the revocation check mode to Offline for both server and client certificates.
defaultCredentials.ServiceCertificate.Authentication.RevocationMode = X509RevocationMode.Offline;
defaultCredentials.ServiceCertificate.Authentication.CertificateValidationMode =
X509CertificateValidationMode.ChainTrust;
Now I don't have to turn off certificate validation or use different validation mode for development (In my case production code will also use self signed certificates for the time being)
I am trying to do push messaging using the java-apns library.
I am currently trying to use it .withSandboxDestination() but I am getting an error saying: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure.
I have read in quite a few places that it is probably due to a missing CA root certificate. The Provider Communication with Apple Push Notification Service says that:
To establish a TLS session with APNs, an Entrust Secure CA root
certificate must be installed on the provider’s server. If the server
is running OS X, this root certificate is already in the keychain. On
other systems, the certificate might not be available. You can
download this certificate from the Entrust SSL Certificates website.
I am using a windows7 machine for my development phase. I opened mmc.exe and added the certificates snap-in (set up for "Computer" - Q1: is this the right thing to do? ) and I can see under Certificates (Local Computer) -> Trusted root certification authorities -> Certificates the following two certificates by Entrust.net:
Entrust.net Certification Authority (2048)
Entrust.net Secure Server Certification Authority
However, on the Entrust.net site there are many more certificates...
Q2: Which of those certificates do I need?
Q3: Am I looking at the right place or maybe java within tomcat is not using my computer's certificates at all?
Q4: Is there a way for me to see the certificate used by apple's gateway.sandbox.push.apple.com, port 2195 ?
Any help is appreciated.
I have a W2K8 R2 SP1 server hosting an SSL web site requiring client certificate. We have a root certificate (self signed), saved in local machine trusted CA store. On client, browser asks for a client certificate and it works fine.
Now, we have another root certificate that is also saved in local machine trusted CA store. Problem is that the browser does not offer to choose client certificate issued by this root CA.
Reason why browser does not prompt is that server is configured (default option) to return a list of trusted root CA to the client to help it limit the list of client certificates to choose from. If we configure the server so that it does not provide this list (HKLM/system/currentcontrolset/control/securityproviders/schannel/sendtrustedissuerlist=0), the browser has not clue and displays all client certificates and then it works fine.
We had a problem like this in the past because the list of trusted CA was too long and thus was truncated when returned to the client but it's not the case here, only 8 trusted CAs are returned.
Also, if I register this new root CA on another (very similar) server, there it works fine, returned trusted list contains the new CA.
I'm really out of clue why this specific server refuses to return my root CA in the list during SSL negotiation, can someone help please ???
Not sure if this helps you or someone else but according to Microsoft and their Windows Server 2012 documentation your problem seems to be related to this:
"If the Trusted Root Certifictation Authorities store that was used contains a mix of Root (self-signed) and certification authority (CA) Issuer certificates, only the CA Issuer certificates will be sent to the server by default".
Keep on mind that you may use different store for "Certificate Trust List" (CTL). "Client Authentication Issuer" store is being checked/used first (by default on Windows Server 2012) and then if empty "Trusted Root Certifictation Authorities" store.
If you were on 2012, you could have manually configured CTL store, but I don't think that option was present on 2008 R2 (though I might be mistaken).
We have an Azure web role deployed that uses HTTPS. We upload a certificate to azure and shortly after the portal refreshes and two more certificate appear. This is not a wild cart certificate and maybe this is standard behavior, but I haven't seen it before.
The original certificate is named something like:
subdomain.domain.com
The three certificates that appear are named like so:
VeriSign Class 3 Public Primary Certification Authority - G5
Class 3 Public Primary Certification Authority
VeriSign Class 3 International Server CA - G3
Are the 3 certificates I mentioned normally generated or is this an issue I should be looking into?
We have a similar deployment that has an ssl, but does not generate these extra certificates. This is what triggered our concern and has me asking why ...?
When you enabled HTTPS endpoint in any web application and bind SSL certificate to it, the certificate bind to HTTPS endpoint is could be a single certificate or it could be a chain and
it is depend on several factors as below:
When the certificate is created as self signed ROOT then it will have only one certificate in the chain. This certificate can not be validated to have SSL tunnel because there is no other part to verify it and that why it is called self signed root
When you buy certificate from a reputed CA (Certificate Authority) in almost all cases you will get 3 (or more) certificates:
2.1. Root Certificate : This certificate is helps to create a SSL tunnel between two machines using PKI security Infrastructure.
2.2. Intermediate Certificate -> This is to create a chain with multiple certs as if needed
2.3. Domain Certificate -> This is for your *.domainname.com or domainname.com
Here is an example of chained SSL certificate at https://mail.google.com
And all of these certificate are chained into one single PFX (if private key embedded into certs) or CER (without any Private Key) so when you deploy only ONE PFX cert, you see the chain is open and all certificates are listed.
If you browser your url and open the certificate view through browser, you will see exactly same chain as you could see in your portal and you can also verify the certificate thumbprint as well to match.