We have a fleet of deployed gateway devices that have a self-signed certificate that they use to make an HTTPS post to our Spring on Tomcat app. This certificate expired, and we cannot issue an update unless we can connect (Catch-22). We need to temporarily ignore the validity of the client SSL certificate in order to get operational again.
We have been trying to figure out where in the Spring XML to put the bean configuration (TrustManager class) to ignore SSL certificate validity.
We are desperate for help. This is not Spring Boot, but Spring MVC secured by spring security using old school XML configuration.
Would not requiring a client certificate help? If so, in <tomcat>/conf/server.xml look for <Connector clientAuth="want"...> and set it to false.
Related
I built an OAuth 2.0 server, and I had verify the implementation of the custom OAuth 2.0 server by postman in chrome, and an nodejs oauth client. It works.
My question is, when I launch Amazon Alexa app in android, and enable the skill. The login UI disappears. It shows nothing. So, I cannot login to get back oauth accessToken.
I use Facebook OAuth service instead now, it works fine. But I still need the custom OAuth 2.0 server to be workable. I doubt it's self-signed SSL certification now, and I will check it in these days.
Any help will be appreciated.
For Self-signed SSL certification, it doesn't work. With a trusted SSL certification, the login UI shows.
Conclusion
After many tests, the custom OAuth 2.0 server for alexa service, must meet following conditions.
The ssl certificate MUST be signed with trusted organization.
The https port MUST be 443, not a custom port. (Ex: 12345)
In some android mobiles, a self-signed certificate or a custom port, the login UI will display. But they all failed at another step for accessToken. The step for authorize is not a problem, but step for token seems to be blocked by alexa app. I suppose alexa app will check the port number, and it doesn't trust self-signed certificate.
We have a web application under default website using client certificate authentication to authenticate its client. It is failing in handshaking with client certificate for authentication and errored out with either timeout or 403 - Forbidden: Access is denied error.
We found below error on system event logs,
When asking for client authentication, this server sends a list of
trusted certificate authorities to the client. The client uses this
list to choose a client certificate that is trusted by the server.
Currently, this server trusts so many certificate authorities that the
list has grown too long. This list has thus been truncated. The
administrator of this machine should review the certificate
authorities trusted for client authentication and remove those that do
not really need to be trusted.
IIS configuration looks much similar to what we have done for this web application on other environments, we verified couple of other checks required for this application
In certificate Store: We verified all server certificate and client cert with its authority hierarchy are available.
Application Authentication: Anonymous
Application SSL Setting: Require SSL/ Accept
ApplicationHost.config: enabled OnetoOneMapping under iisClientCertificateMappingAuthentication also added base64 certificate mapped with service accounts
I am not sure this authentication issue has to do anything with above error message in event log.
I know that this is probably too late to help the OP, but for anyone else with this event log message, there is a well-structured post on this issue at https://www.codit.eu/blog/2013/04/03/troubleshooting-ssl-client-certificate-issue-on-iis/, which suggests:
There are two solutions to solve this issue:
The first solution is to clean up the Trusted Root Certification Authorities store (Local Machine) and remove all unnecessary certificates. Be aware that you don’t remove certificates that are required by Windows.
A second solution is to configure Schannel to no longer send the list of trusted root certification authorities during the TLS/SSL handshake process. This can be done by adding this registry entry on the web server
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Value name: SendTrustedIssuerList
Value type: REG_DWORD
Value data: 0 (False)
I found this answer on how to use Web.Config to make IIS require SSL client certs for a specific MVC controller but I can't figure out how to make it work if the user visits any other controller first.
The purpose of this requirement is that the client certificate is only used for login to access secured portions of the application. Users who are not logging in should not be prompted for a certificate.
Example: SSL cert required for Auth controller
If the user goes directly to domain.com/Auth they are prompted for a certificate as intended. However, if the user goes to domain.com/Home then clicks Sign On (sending them to the Auth controller) they receive a response of HTTP 403.7 indicating the site requires a client certificate.
Turned out to be a browser caching issue.
We have Web API 2 application exposed to outside vendors for various integrations. We're adding a new one with DocuSign through their Connect service and they will be signing their requests with their X509 certificate. I would rather not install the certificate on the server itself because we add new servers and deployments often based on load.
Here is my plan, and I'd like to know what the security risks are with it (assuming it will work at all).
DocuSign provides their X509 certificate for download. I want to place that *.cer file in my Web API application's ~/App_Data folder, along with any other certs from any other vendors. I will use a DelegatingHandler to grab the client certificate from the Request. I would then use the X509Chain class as described here to load all certificates from the ~/App_Data folder and to verify the request certificate.
From there I would map the certificate subject to a role and add that to the current thread to provide authentication for specific routes.
I've gathered from my research that this method would be less secure than installing DocuSign's certificate to the server's root store - is that correct? And how much less secure?
At the end of the day I'd like to (1) verify that the request is coming from who it says it's coming from, and (2) add roles based on the verified requester for authentication.
A number of Countries have implemented electronic id cards, that their citizens can use to securely access online facilities like banking.
I am interested in learning how to support these cards, but tracking down documentation on how to do this from an IIS hosted website is a real PITA: In MSDN for example the bulk of the smartcard documentation covers the end to end scenario of linking smart cards to domain logins in a corporate environment.
I am just trying to authenticate the holder of - for example, a Spanish DNI-e card and perform an OSCP validation of the card via http://ocsp.dnie.es/
Now, its seems that, rather than explicitly detecting the smart card insertion, I need to create a login page on the server with SSL client authentication forced - but how do I configure one request to require ssl client authentication and to pick the correct client certificate?
Indeed, configure your server to require client certificate authentication. You will receive the client authenticator details in the headers.
You can force to only accept specific certificates by configuring the public root certificate of those client certificates on the server and removing all others that you are not interested in. In the authentication request going from your server to the browser, only the root certificates are listed that are trusted on your server system. The client browser will only offer client certificates that are somehow related to that root.
In an Microsoft environment you would configure your IIS to require SSL on your login page. Additionally, require SSL client authentication using a certificate.