I'm trying to use the tomcat[7]-maven-plugin to deploy my war to my tomcat instance. However, it's running over https with a self-signed cert. So, I'd like to import the cert into a truststore in order to deploy it. I thought the truststoreFile parameter might let me specify the custom truststore I'd like to use for the action, but it doesn't seem to. Can anyone tell me what it does?
Truststore in this context is used to validate certificates provided by the clients to the server (lookup SSL client certificate). I'm not too familiar with tomcat but I would imagine that the parameter is used to point to a custom truststore (which could contain custom trusted certificates or CA's) Server's own certificates, self-signed or not, go to a keystore.
Related
I try to run a microservice (based on Eclipse Microprofile) on OpenLiberty (v20.0.0.1/wlp-1.0.36.cl200120200108-0300) on Eclipse OpenJ9 VM, version 1.8.0_242-b08 (en_US))
I run the server as the official Docker image (open-liberty:kernel)
In my service I try to connect to another rest service via HTTPS
Client client = ClientBuilder.newClient();
client.target("https://myservice.foo.com/").request(....);
This throws the following exception:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
I already added the features 'transportSecurity-1.0' and 'ssl-1.0' into the server.xml file:
<featureManager>
<feature>jaxrs-2.1</feature>
<feature>microProfile-2.2</feature>
<feature>transportSecurity-1.0</feature>
<feature>ssl-1.0</feature>
</featureManager>
and I also tweaked the jvm.options file like this:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=7777
-Dhttps.protocols=TLSv11,TLSv12
-Djdk.tls.client.protocols=TLSv11,TLSv12
-Dhttps.protocols=TLSv11,TLSv12
-Dcom.ibm.jsse2.overrideDefaultProtocol=TLSv11,TLSv12
But nothing helps to get rid of the exception.
How is the correct configuration for OpenLiberty to enable outgoing ssl connections?
Liberty doesn't trust anything over ssl by default, so unless the service you are connecting to uses an identical keystore/truststore file, or you've otherwise configured your service to trust the microservice in some way, you can get that exception. If this is the problem, something like this will probably be seen in messages.log as well:
com.ibm.ws.ssl.core.WSX509TrustManager E CWPKI0823E: SSL HANDSHAKE FAILURE: A signer with SubjectDN [CN=localhost, OU=oidcdemo_client, O=ibm, C=us] was sent from the host [localhost:19443]. The signer might need to be added to local trust store [/Users/tester/tmp/liberty/20003wlp/wlp/usr/servers/urlcheck/resources/security/key.p12], located in SSL configuration alias [defaultSSLConfig]. The extended error message from the SSL handshake exception is: [PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target].
How to manually patch up the truststore is documented here,
https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_add_trust_cert.html
but what you will probably want to do in a docker environment is modify your images to either include a common keystore/truststore, or read one from outside somewhere (such as a kubernetes secret). By default, each docker image creates it's own unique key/truststore, and they won't be able to "talk" over ssl.
If you only need to communicate with services that have a certificate signed by a well-known authority, you can add
ENV SEC_TLS_TRUSTDEFAULTCERTS=true
to your Dockerfile (20.0003+) to enable that.
As mentioned by Bruce in the answer above, Liberty doesn't trust any certificates by default. If you are making outgoing connections from Liberty to a server, you either need to add their certificate to the truststore you have configured OR you need to trust the JRE's cacerts if the remote endpoint is using a certificate from a well-known CA.
When you say you are using Let's Encrypt certificates, do you mean the remote end-point is using them, or your Liberty server is?
If the remote end-point is, most JRE's cacerts include Let's Encrypt in their cacerts. If the Liberty server is using a certificate signed by Let's Encrypt, that doesn't really have an effect on the outgoing connection unless you are using mutual SSL authentication.
As an FYI, if you are using a certificate signed by Let's Encrypt in Liberty as the default certificate, we will be adding built-in support for the ACME protocol in a few releases. See here for progress: https://github.com/OpenLiberty/open-liberty/issues/9017
I am working in Ec2 instance. I have connected my php files like http://13.57.220.172/phpinsert.php. But it is not secured site. So i want to convert http into https://13.57.220.172.
I have cloudflare ssl. When i try to add ssl certificate. It shows
com.amazonaws.pki.acm.exceptions.external.ValidationException: Provided certificate is not a valid self signed. Please provide either a valid self-signed certificate or certificate chain. Choose Previous button below and fix it.
i have enclose the image with it.
So how can i get the self signed certificate. is there any online tool available.
I think the error message your seeing has to do with this sentence:
If your certificate is signed by a CA, you must include the
certificate chain when you import your certificate.
from https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html.
Since it sounds like you're not yet in "production" mode, I'm guessing you're not particularly attached to your existing certificate, but just want a certificate to be able to do HTTPS on your web server (and don't really care if it's self-signed).
If you want to use AWS Certificate Manager, I think it would be easier to just let them (AWS) issue you a certificate instead of trying to import one from somewhere else. AWS doesn't charge anything for certificates. https://docs.aws.amazon.com/acm/latest/userguide/acm-billing.html
Even if you get the certificate setup in AWS Certificate Manager, that's not going to be installed directly on your EC2 instance, but rather (most likely) on a load balancer in front of your web server, which will add a little complexity to your setup. https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html
If all you want to do is use HTTPS on your web server, Let's Encrypt (also free) is probably a simpler option. If you are using AWS Linux 2, there are instructions for getting a certificate here - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html
Well, add to the points which #jefftrotman has already mentioned.
If your expectation is to just secure your IP address using HTTPS you can achieve that using the below approaches:
A SELF SIGNED certificate that you can create using OpenSSL.
You can also get an SSL certificate from a trust signing authority like (GoDaddy or VeriSign) or Let's encrypt.
The only requirement in the second point is that for getting a certificate from a valid signing authority you need to have a domain name like "myphpapp.com" and then use this domain to get the SSL certificate.
The below details are in case you want to use AWS ACM(Amazon Certificate Manager)
If you prefer ACM, you can get the free Public SSL certificate which you can map to the IP address and your web application will be secured.
If your requirement is to add SSL certificates (like PEM files) to a web server like
NGINX or Apache then you first need to create a Private CA using in ACM and then you using this CA you will be able to create Private SSL certificates. After creating those you can export the files and add those files to the configuration file. (try to use Amazon Linux 2) ec2 image for ease.
I have WSO2 API manager deployed in AWS EC2 instance.
I have purchased a SSL certificate via sslforfree.com. I tried to import it via keytool command. But its not working and throwing error. It gives me
KrbException: Cannot locate default realm
How can I associate this certificate with the API Manager? I don't have a domain name for WSO2 and I access it via IP address.
Is it possible for have CA signed certificate in this case?
In case if I want a domain name for this EC2, how can I have one?
You can import the certificate inside Carbon. Log into <your_server>:9443/carbon as admin. After that go on Main -> Manage -> Keystores -> List
If you're still using the default settings you'll have the wso2carbon.jks entry here. Click on Import cert, chose your cert file and click on Import. Your certificate should be working after this.
there are several topics in this question:
I tried to import it via keytool command.But its not working and
throwing error.It gives me KrbException: Cannot locate default realm
The keytool gives you this exception? It would be useful to provide the keytool command you've used. There's not reason for that exception.
please not that the certificate CN must be the same as the fqdn (domain name) of the server (how your browser access it).
How can I associate this certificate with the API Manager?
There are two options.
Import the keypair (private key and certificate chain) into a keystore and configure the APIM to use the keystore (in the repository/conf/tomcat/catalina-server.xml)
Have a reverse proxy server (Apache HTTP, NGinx), and configure the SSL on that proxy server. This is my favorite approach .
See: https://docs.wso2.com/display/AM210/Adding+a+Reverse+Proxy+Server
Then you have control over who/where can access the carbon console, store and publisher.
I don't have a domain name for WSO2 and I access it via IP address. Is
it possible for have CA signed certificate in this case?
Certificate authorities don't provide IP based certificate, as they can validate ownership/control of a domain name, but not of the IP address.
You can create (and made trusted) your own CA and certificate (good for PoC, DEV environment, ..) but in long run you'll need a trusted certificate on a hostname.
In case if i want a domain name for this EC2 , how can i have one ?
You can always buy one :D For start - when having EC2 instance with a dynamic IP address, you may use some dynamic dns service (e.g. https://ydns.io/ , just search for more if you wish)
When an application optionally allows you to specify a certificate which represents a certificate authority, what is that doing?
Does that basically set that cert as a "trusted" certificate?
Specific example:
Kibana communicates with elasticsearch. When you configure kibana, you can set the following configuration value:
elasticsearch.ssl.ca
The documentation says this value is an "Optional setting that enables you to specify a path to the PEM file for the certificate authority for your Elasticsearch instance." (source)
Within that same config you're also specifying a certificate and key that can be used for communication with the elasticsearch instance.
If the setting is optional it means that the default behaviour is to use the system Root CAs to validate the SSL Server certificate used by your Elasticsearch instance. If you used a standard commercial SSL Server certificate this should be enough.
Yes, you are setting that certificate as a Root CA but only for this application.
Using the setting you can specify the Root CA used to generated the SSL Server certificate. This is useful if you:
use a selfsigned certificate
use a Root CA that is not available in the system Root CA repository
need to have stringent security settings limiting subset of Root CAs trusted by your application.
I have the following issue: I have a domain that hosts a) a website on port 443 (Apache) and b) a web app with Spring Boot (Tomcat) on port 8443. Both are using the same certificates. For Tomcat I generated a keystore that consists of the private key/certificate, intermediate and root certificate. Visiting the website is not an issue at all.
Now, when I visit the webapp from e.g. Chromium or from my smartphone I can access it and https works just fine (certificate is trusted and I can view the certificate chain). If I instead try opening it in Firefox or use openssl s_client -connect domain.com:8443 the connection is not secured and only my certificate, but neither the intermediate and nor the root certificate are provided.
Now I don't understand how that happens, whether maybe Chrome recognizes the certificate chain from the issuer field of the certificate or asks the app server to provide further parts of the chain, and Firefox/openssl do not.
Any hint about how to make this running would be greatly appreciated!
BR Johannes
BTW about the keystore creation: I created an empty keystore, added the root, then the intermediate and then my certificate + key.
Seems I made a mistake on how to create the keystore, just importing the certificate chain and the key pair wasn't enough. I had to append the certificates of the chain to my certificate (using KeyStoreExplorer or as described in this answer.
How it came that Chromium accepted the certificate anyway is still a mistery to me, though.