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).
Related
I have a business process which send messages to SAP via soap endpoint exposed by them.
I am using WCF-BasicHttp Send Adapter(In-Process).
As you can see below, earlier the url was http, now they have moved their system to cloud so now they have https endpoints.
I wanted to test this change from http->https, so I have modified the url to https, fill in the credentials for basic auth. it working fine in Test system without SSL Certificate, I need to make sure it wont cause any issue after moving to production system.
My Question is,
1/ Will it work in Production system too as its in TEST without SSL Certificate ?
2/ or Do I need to apply SSL for WCF-BasicHttp Adapter, if yes How can I do that ??
If you are moving to https URL, Certificate is must for SSL/TLS handshake. Many times, Certificate used by specific endpoint is signed by a third party Trusted Root CA e.g. Trustwave, DigiCert etc and these Root CA certs are already trusted on most of the systems. It’s possible in your test system, your endpoint certificate Root CA is already trusted and that’s why you did’t need to install the certificate. In order to check this, you can do following:
Browse your https service url in browser in chrome/IE
Look for Security/Lock sign to find it’s cert. Clicking the lock sign will open certificate.
Check the certificate root by going to Certification Path. You should see a chain of certificates in path. A cert can be by signed by just root CA Or by Intermediary CA first and then root CA. e.g.
—- Trustwave Root
—- Trustwave Intermediary
—- service cert
Or
—- Some Root
—- service cert
Check if Root CA is in your Trusted Root store of system. And Intermediary Cert (if applicable) is in Intermediary Cert Store. You can check this by opening certificate mmc snap-in using mmc command in Windows->Run and adding Certificates snap in of local computer.
If Root CA Cert and Intermediary Certs are not in your system store. SSL/TLS handshake will not complete successfully and BizTalk send port will not work.
If these are installed, you should be good. Otherwise install these certificates in local computer stores.
Another way to verify if endpoint certificate is trusted on a BizTalk system is to login with service account under which your send host is running and then browse the URL in IE. If you don’t get any Cert error, and URL opens such as wsdl URL, then you are good. If you get a cert error, this means end point certificate is not trusted and you need to install the certs as described above.
Some references:
View Certificate
Working with Certificates
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 read about server authentication over web and got to know that issuer Root CA should be imported into Trusted Root CA on both server and client machines for mutual authentication.
Now let's say it is banking application.
The user connects to the bank server for the first time:
Server returns server certificate to validate itself to client.
Client gets the certificate and validate with trusted Root CA authority which has signed this server certificate earlier.
Client sends its certificate and server validate with trusted Root CA
authority which has signed this client certificate earlier.
Now communication starts.
In Step 3 I understand that the trusted Root CA authority is installed on the server when the server gets deployed.
However, in Step 2 when the client machine connects for the first time (and can dynamic connected from any machine), how does the Root CA authority got installed on the client machine?
Root CA certificates are usually preinstalled in operating system and software (when software use its own trust store). Administrators may use their tools to deploy additional roots (which are not common, for example, organization's private roots).
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
During SSL handshake, the browser downloads any intermediate certificate from the host web server using the URL provided if needed. I believe browser comes with the pre-installed certificates from public CAs having only the public key of the root certificate.
1) When calling a https url using a standalone java program [https://xyz.com ..which is using Verisign certificate], i do not need to add that Certificate to any truststore since its root public is already available in jdk's cacerts truststore file. Is this correct statement?
2) When i run the same program from application server, it requires to add all the intermediate certificate to server truststore individually. Why this works in different way.
If the trust chain for the servers certificate is: root-intermediate#1-intermediate#2-server and the client (browser) has root as trusted CA in its CA store, it needs a way to verify the servers certificate by checking the complete chain up to the root. And because the client usually has no knowledge of the intermediate CAs the server needs to provide them.
Sometimes it seems to work w/o providing these intermediate CAs. First, the browsers usually cache the intermediate CAs they got and thus if intermediate#2 is the same as already seen by another server the verification will succeed, but only for the clients who visited the other server before :(
Another way is to provide a URL inside a certificate, where the issuer certificate can be downloaded, e.g. server could provide a link to the certificate for intermediate#2, intermediate#2 could provide a link to intermediate#1. In this case the client could download the missing certificates. But, this features is not universally adopted, e.g. some browsers might provide it but SSL libraries outside of the browsers usually don't.