I am rather confused by the purpose of the trustore file in a tomcat server.
I.e use of the truststoreFile parameter when setting up a TLS enabled connector.
According to the tomcat docs:
truststoreFile
The trust store file to use to validate client certificates. The
default is the value of the javax.net.ssl.trustStore system property.
If neither this attribute nor the default system property is set, no
trust store will be configured.
To me this is telling me that for an inbound connection to my tomcat server, this is where I would store certificates that a client would present. (e.g. a users browser)
Would I really put in 3rd party CA certificates here or other 3rd party server certificates, if my tomcat server wants to make an outbound connection to a TLS enabled server (e.g. an LDAPS server)
As per my understanding the place to do this is the cacerts file.
Is my understanding of the truststore wrong?
Yes, you are right, it is quite confusing.
If you need to make an outbound connection a 3rd party, you need to add the certificates to cacerts.
There is a very popular "signing, validation, etc." service for government-owned companies here in Spain, #firma, that just changed its wildcard server certificate and we had to add it to cacerts.
Related
I was able to achieve ssl offloading with Haproxy. So great product and appreciate that capability!
With that said, I need to doing mutual TLS but am a little confused on how that will work with the ingress controller configmap.
Going through this reference i've created a client cert, intermediate cert and root cert.
To note, I am terminating the ssl cert (which is from letsencrpt) on the load balancer currently.
However, the client cert and org CA are different than the lesencrypt tls/ssl cert that I have assigned as the SSL now; does that matter?
So, the first question I would have is does the ssl-certificate have to be set to the CA that will sign the client and server certs or can I just use the new ones I created in the instruction.
Setting up the configmap.
This is the part i'm confused on.
You can setup server-ca and server-crt but I don't think that applys here because after the ssl offloading there is nothing meant to be checked. However, I do want mTLS via the ssl termination.
So there is an configuration client-ca
Sets the client certificate authority enabling HAProxy to check clients certificate (TLS authentication), thus enabling client mTLS.
NB, ssl-offloading should be enabled for TLS authentication to work.
The client in this case being the actual client I want which is the device/frontend. Not the loadbalancer acting as a client to the backend server.
When I look at how this is setup:
frontend mysite
bind 192.168.56.20:80
bind 192.168.56.20:443 ssl crt /etc/haproxy/certs/ssl.crt verify required ca-file /etc/haproxy/certs/intermediate-ca.crt ca-verify-file /etc/haproxy/certs/root-ca.crt
http-request redirect scheme https unless { ssl_fc }
default_backend apiservers
Is it possible to do the same with the controller configmap as what is listed here below? There's a lot more going on that what I am seeing as flags / configurations that are in this methodology of applying client mTLS. Is there a way to achieve this in kubernetes without configmap?
The ssl parameter enables SSL termination for this listener. The crt parameter identifies the location of the PEM-formatted SSL certificate. This certificate should contain both the public certificate and private key.
You can restrict who can access your application by giving trusted clients a certificate that they must present when connecting. HAProxy will check for this if you add a verify required parameter to the bind line, as shown:
the ssl argument enables HTTPS
the crt argument specifies the server SSL certificate, which you will typically obtain from a certificate provider like Let’s Encrypt
the verify required argument requires clients to send a client certificate
the ca-file argument specifies the intermediate certificate with which we will verify that the client’s certificate has been signed with our organization’s CA
the ca-verify-file argument (introduced in HAProxy 2.2) includes the root CA certificate, allowing HAProxy to send a shorter list of CAs to the client in the SERVER HELLO message that will be used for verification, but keeping upper level CAs, such as the root, out of that list. HAProxy requires the root CA to be set with this argument or else included in the intermediate-ca.crt file (compatibility with older versions of HAProxy).
Also, my reasoning for now wanting to use letsencrypt and rather a private CA is because I can't renew device certificates every 60 - 90 days. That would not be efficient. In this case, and please let me know otherwise, I think it better to use either a real key/cert provider or in development testing utilize the openssl certs like in the HAProxy instruction.
It's odd but you really have to think about what a "client" is with these abstractions because I would never use this for a normal web page login but rather the server to server communication and in that sense this server is a client to this server. Or in my case this device is a client to this loadbalancer.
A Certified Domain should be accessible only if SSL public certificate of the domain is already present in client's trust store. If not, client should prompt to import server certificate instead of getting it from tomcat server automatically(Via SSL handshake)
This will not work: the server has no knowledge which CA certificates are known to the client so the server cannot decide what to send to the client. Also, the server can only send a certificate to the client but not make the client import a new root CA - no matter if with or without prompt.
Apart from that it makes no sense: the idea of TLS/HTTPS is that the client will only connect to a server which identity can be verified. If the server can make a client import a new trusted root CA an attacker could do the same and thusman in the middle attacks would be possible.
If one instead just want to know if the client will trust a specific certificate or not one could include a resource (image, script...) served with this certificate into a known good HTML page and then check with some script in the page if the resource was loaded successfully. This check could also result in a redirect of the client, for example to some page describing the problem and linking to the correct root CA.
Looking to port Outbound SSL configuration from Websphere to JBoss. In my case, JBoss is the client. It wants to pass a client cert to a remote machine as part of a 2-way SSL communication.
In Websphere, you explicitly specify...
keystore / keystore password (where are the certs?)
certificate alias (which client cert to apply?)
matching outbound url pattern (when do i apply the client cert?)
You may have many of these configurations. Between these 3 pieces of info, the container can selectively choose when/which client certificate to include when making outbound SSL calls.
What is the JBoss way of doing the same thing as I described above ?
Can this be done by simply configuring your JRE ?
Are there parts of this that cannot be done in JBoss and/or java?
Thanks,
Wade.
Good afternoon,
I'm getting the following error trying to use a BizTalk send port to talk to a web service:
"System.InvalidOperationException: Cannot find the X.509 certificate using the following search criteria: StoreName 'My', StoreLocation 'CurrentUser', FindType 'FindByThumbprint'
The send port is configured as type 'WCF-WShttp', 'Transport' security mode, 'Certificate' credential type.
I have a self signed certificate that has the same thumbprint value as shown in the bizTalk configuration dialog. I've checked the file shows the correct thumbprint and it is not expired.
I've tried installing it in the all the following stores:
"Current User": Personal, Trusted Publishers, Trusted People, Trusted CA's
"Local Computer": Personal, Trusted Publishers, Trusted People, Trusted CA's.
When I go to the wcf send port configuration in the BizTalk management console it allows me to browse available certs. Our cert appears and lets me select it.
I made sure the service account for biztalk is added to the cert permissions.
Any suggestions?
Thanks!
The client certificate needs to be installed in BizTalk host user account certificate "Personal Store", also make sure any root certificate (if any) is in trusted store and then set it on adapter configuration.
Following these procedures should work. https://msdn.microsoft.com/en-us/library/gg634534(v=bts.70).aspx. Probably the most important thing to note is that you must be logged on to the server with the actual account that is running the adapter handler's host instance service. And for a self-signed certificate I think you just need to add it to the Trusted Root CAs for that account too.
Did you copy the thumbprint directly from the mmc to your BizTalk Send Port.
First try to copy it to notepad++ and check if you see any special characters.
If that's the case remove the special characters and then copy that thumbprint to your BizTalk Send Port.
I have configured an Apache httpd website with SSL client side certificates so that only users who have installed the correct certificate in their web browsers can access the website.
If there is only one client side certificate installed the web browser will automatically select it (it is not the default, but it can be configured somewhere in the settings dialog). But if a user has more than one certificate installed, the web browser presents a list of certificates and the user has to pick the right one to continue.
The question is: Is there a way to configure httpd to send a hint so that the web browser can automatically select the required certificate?
The SSL (TLS) protocol only allows the server to specify two constraints on the client certificate:
The type of certificate (RSA, DSA, etc.)
The trusted certificate authorities (CAs) that signed the client certificate
You can use "openssl s_client" to see which CAs your Apache server trusts for client certs. I do not know how to configure Apache to change that list (sorry), but I bet there is a way. So if you can limit the list to (say) your own organization's CA alone, then you will have done all you can to allow a Web browser to select the client cert automatically.
As Eugene said, whether the browser actually does so is up to the particular browser.
I'd say that as selection of the certificate is a client-side task, there's no definite way to force the client use this or that certificate from the server side.
In addition to what #Nemo and #Eugene said, by default, Apache Httpd will send the list of CAs it gets from its SSLCACertificateFile or SSLCACertificatePath configuration directives.
However, you can force it to send a different list in certificate_authorities using the SSLCADNRequestFile or SSLCADNRequestPath directives and pointing them to another set of certificates. Only the Subject DN of these certificates is used (and send in the list). If you want to force certain names, you can even self-sign these certificates with whichever name you want. I've tried this (in conjunction with SSLVerifyClient optional_no_ca, and you can get clients to send certificates for CA certificates that the server doesn't actually have. (This isn't necessarily useful, but it works.)