I received the following question. Any help would be greatly appreciated!
What I need to be able to do is configure SSL to validate the target endpoint’s SSL certificate against the base trusted roots (typically provided by the OS and/or Java). There is no documentation that tells me how to turn on SSL certificate validation or if I add a TrustStore if it will guarantee that the SSL cert is validated against that. The only tutorial I see that is related is for SSL Client Auth, which we are not using.
Validation of backend SSL server certificates is explained on this page. Note that the page documents how to achieve mutual authentication, where the gateway would both validate the target server's SSL certificate (which you want), and send a certificate to the target as identification (which you do not want).
To validate the target's certificate, you create a truststore and upload all certificates in the trust chain for your target server. The documentation mentions only uploading the target server's certificate (which works if your target server is using a self-signed cert), but you'll want to upload the entire trust chain of certificates if you are using a non-self-signed cert. Creating and uploading to the truststore is shown in step 6 on the page above.
Then, you'll want the target endpoint configuration to look like this:
<TargetEndpoint name="default>
<HTTPTargetConnection>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>false</ClientAuthEnabled>
<TrustStore>myTruststore</TrustStore>
<IgnoreValidationErrors>false</IgnoreValidationErrors>
</SSLInfo>
<URL>https://myservice.com</URL>
</HTTPTargetConnection>
</TargetEndpoint>
ClientAuthEnabled=false indicates that the gateway will not send a certificate to the target.
IgnoreValidationErrors=false will cause the connection to abort if the certificate returned by the target cannot be validated using the certificates in the truststore. IgnoreValidationErrors=false is the default, so you could leave it out and it would work as desired. However, if you are having problems communicating with your target server, it may be useful during testing to set the ignore flag to true to allow communication even if the certificate fails verification (just to isolate your problem). Just be sure to set it to false in production.
The xsd schema for the SSLInfo element can be found here.
Related
i m using Weblogic 12c.
I would like to set up client certificate authentication (2-way SSL). But i do not want to enforce client certificates for the whole server. Basically, in our webapp most of the servlets should work with regular 1-way SSL (only server certificate is verified) without requiring client to provide the certificate. But for one of the servlets client certificate authentication is needed.
I have set up similar thing for Glassfish using separate module for the servlet where 2-way SSL is required with web.xml deployment descriptor with login-config element indicating CLIENT-CERT authentication type. I have also set up appropriate security constraints, roles and groups.
However this does not seem to work with Weblogic. In the admin console under SSL i see "Two Way Client Cert Behavior" with 3 possible values: "client cert not requested", "requested but not enforced" and "requested and enforced".
If i set it to "not requested", client does not present any certificates at all (even though i have the same web.xml with CLIENT-CERT which works with Glassfish). Setting to "requested and enforced" is not an option. I also tried setting to "requested but not enforced" but that's also bad since the browser will ask for client certificate even for those pages where it is not needed (most of them) and we don't want that behavior.
Basically, it seems to me that Weblogic wants to enforce 2-way SSL for the whole server, but that's not what we need, we need it only for one webapp module. Is it possible to do so?
Edit:
To clarify, i set up DefaultIdentityAsserter and created custom UserNameMapper to map client certificate to user name. The problem however that if SSL setting (described above) is set to "not requested" then client certificate is not presented at all so the server cannot authenticate and i get 401 response. And i can't use the other 2 SSL settings because then the server will ask for client certificate for all webpages and that's not what we want.
You could create 2 Network Channels. See NetworkAccessPointMBean in WLST, or Environment/Servers/yourServer/Protocols/Channels in Admin Console.
Channel 1: SSL enabled w/ one-way SSL, on a specific port
Channel 2: SSL enabled w/ two-way SSL and client cert enforced, on a specific port
Then, access your web module on the appropriate port based on your client cert requirements.
This would only require one server.
For your specific need, I would create 2 managed servers, setting up only one with 2 way SSL.
You can then deploy your applications on the appropriate managed server, depending if you want the 2 way SSL or not for it.
Then you need to add a reverse proxy in front of your WebLogic server in order to forward your user to the correct port, as you probably don't want to expose several ports.
I hosted an ASP.NET Web API project in my Windows 7(IIS7) developer machine on HTTPS(443) and SSL Required ticked with Require Option true.
For testing I give its host header value : www.certtest.com, and the same I add in host file of local machine.
Also we have a W2k3 machine where we've configured the CA and obtain test certificates from it.
We import same certificate in IIS7.0 for client authentication.
When we try access site, the first time it asks me for certificate and after that certificate get installed with root certificate in my local store but i see 403.7 Forbidden error immediately.
Also, I tried with self signed certificate.
Same problem with that too.
Do we require a valid trial certificate for client authentication by Thwate type CA to accomplish this?
Yes this is a case where we don't have valid certificates, for testing you can set SSL Settings as Accept and see if things work fine for you.
However you will need valid certificates for the same.
My question is so far, a purely theoretical one.
I want to make a CMS that supports multiple sites.
The question I haven't been able to figure out so far is this one:
How do I attach the ssl certificate for https protocol from the code-behind, instead of attaching it through the hosting interface or on the iis itself (the main problem is that i want a different ssl certificate for every site, instead grouping them on one certificate, which allows maximum of 5 domains, and will still say they are the same entity)
This is not solvable on ASP.NET level.
The reason is that with HTTPS requests the SSL handshake (where certificates are presented) is performed before the client sends HTTP request, from which you can learn the domain.
The only exception is server-name-indication extension in TLS, which lets the client specify the desired domain in SSL request. But this extension is not supported by many clients and it's not present in still used SSL3 protocol version. And even with this extension it's the SSL server that decides which certificate to present.
As mentioned by Eugene, administering the SSL cert is beyond the level of ASP.Net; however, you may create some form of administration routine to execute the command-line tool for IIS7 (and up) AppCmd.exe to manage the certs:
ie (shell command --security rights is important):
appcmd.exe set config -section:system.applicationHost/sites /+"[name='Default Web Site'].bindings.[protocol='https',bindingInformation='*:443:']" /commit:apphost
The System.Security.Cryptography.X509Certificates.X509Certificate namespace might also come in handy.
I am trying to set up smart card authentication for a website that I have created. Setting authentication to Windows and setting SSL to required I can get the smart card reader to pop up when they go to the web site. There are 2 credentials on the card though and only one of them is showing up as an option (the information I need is on the other credential). I asked a co worker and he said in IIS 6 there was a way to specify a location on the smart card to look for certificates. I have been researching this issue for about a week now but haven't been able to find a solution to this issue yet. Does anyone know how to do this?
IIS really only knows about certificate-based authentication, not smart-cards per se (which is really just a form of cert-based authentication). Configure your site to use certificate-based authentication, eg "Require Client Certificates" and IIS will chain the call down to Windows security, which, in turn, recognizes that among the sources for identity certificates is the smartcard reader. Depending upon your site requirements, you may also need to enable Certificate Mapping, which translates certificates into Windows account identities.
When certificates are required (or accepted) IIS will ask for a client cert in the SSL negotiation when the session is started. IIS will send a list of the Certificate Authorities it trusts to the client. The client then takes those and sees which match the list of Certificate Authorities it trusts. It then take sthe list of common entries and checks to see if it has any certs issued by a CA both sides trust. Generally, if there are none it will simply not send a cert and the request fails if the cert is required. If there is just one certificate IE will generally send that without asking the client which cert to send, but it will prompt for a PIN if required. Finally, if there are more than one certificate issued by a CA both sides trust then a dialog box will be presented to the client asking which cert to use.
In this case it sounds like perhaps the credential (certificate) you want the client to send is issued by a Certificate Authority that isn't trusted by one or both sides.
Issues have been asked many times about how to handle self-signed certificates with Java and implementations are often provided. However, I'm not sure that these implementations will give me the security/trust I am looking for.
My circumstance is as follows: I have a client program connecting to our server application. Both of these we have complete control over. Our client post's a stream using https to a URL at our server, and the server responds. Currently (and this is what I'm trying to fix) the server has a self signed certificate. Java doesn't like this and FOR TESTING ONLY, we are pretty much ignoring the certificate altogether by trusting any certificate.
I have little knowledge of SSL. My boss says we can use our self-signed certificate and it will be secure as long we don't make our crypt. key public. This sounds correct to me, but a lot of posts say self-signed cert's are automatically vulnerable to man-in-the-middle attacks. Does this mean SSL sends the crypt. key along with the certificate?
Since we have control over both ends, should we just encrypt our data ourselves with a secret key, and decrypt it at the end using our key? Or is there reason to use SSL?
Instead of trusting any certificate blindly (which would make the connection vulnerable to MITM attacks), configure your Java client to trust that particular certificate. Self-signed certificates do not inherently make SSL/TLS connections vulnerable to MITM attacks, they just make their distribution and the evaluation of trust more specific to this particular deployment (i.e. you have to configure it manually).
You can do this in at least 3 ways (pick the easiest one for you, I'd suggest bullet point #2):
Import the server certificate into your client's global trust store (lib/security/cacerts in your JRE directory). This will make all applications run with this JRE trust this certificate.
Import the server certificate into another truststore (possibly a local copy of lib/security/cacerts) and make this particular application use this truststore. This can be done using the javax.net.ssl.trustStore system properties.
Make your client application use an SSLContext initialised with an X509TrustManager configured to trust that certificate: either something written manually or a trust manager coming from TrustManagerFactory initialised by loading a local keystore that contains that particular certificate (as in the previous method).
You'll find more details about all this in the JSSE Reference Guide.
(This answer to a similar question should give you the details for doing all this properly, in particular keytool -import ....)
The arguments against self signed certificates mainly apply to web-applications. Since with the current infrastructure a browser won't be able to validate your self-signed certificate.
Since you have control over the client, you can simply hardcode the certificate you expect into the client. For example you might calculate the sha1 hash of the certificate, and check if that matches the expected value. That way you don't even need to trust hundreds of CAs.
To achieve secure communication you need to first ensure your talking to the right computer. When the client first attempts to establish a secure connection, it pings the server and the server responds with its cert. At this point you MUST validate the servers cert before continuing. The cert includes a public key and signature that can be used to ensure the cert is valid. For example, in web browsers this means checking to see it's been signed by an authority listed as trusted in your browser settings, if that check fails you'll see red warnings in your browser. In your case this will mean you have manually (or in code) added the servers cert into a trust store so that it is trusted.