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.
Related
THIS IS STILL AN ISSUE ANY HELP WOULD BE APPRETIATED
I am having an issue setting up TLS through a custom CA between Kibana and Enterprise search. I have the default x-pack security set up for the interconnection of my Elasticsearch nodes with both Kibana and Enterprise search, which was done according to the following docs: minimal security basic security ssl/tls config. I can successfully run Enterprise search through http, however my issue arises when I enable ssl/tls for ent-search..
When I have https configured for ent-search using this doc, the server is "running", however I receive an error after boot and Kibana throws an error when attempting to connect.
ent-search error (non corresponding with Kibana's hit to the ent-search hostname, this error raises shortly after ent-search is "starting successfully", but isn't fatal)
[2022-06-14T20:37:45.734+00:00][6081][4496][cron-Work::Cron::SendTelemetry][ERROR]: Exception:
Exception while performing Work::Cron::SendTelemetry.perform()!: Faraday::ClientError: PKIX path
building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target
Kibana error (directly corresponding to when I ping http://obfuscated-dns:5601/app/enterprise_search/overview)
[2022-06-14T20:43:51.772+00:00][ERROR][plugins.enterpriseSearch] Could not perform access check to
Enterprise Search: FetchError: request to https://obfuscated-dns:3002/api/ent/v2/internal/client_config
failed, reason: unable to get issuer certificate
The steps I took to generate said certificate were: I created a csr on my server using elasticsearch-certutil csr along with a yml file which specified the distinguished name, I sent the unzipped csr to my CA (Digicert), uploaded the signed certificate and intermediate certificate provided by Digicert to my server, used openssl to generate a keystore using the signed cert and that private key generated along-side the original csr, then finally converted the keystore to .jks format using keytool.
From my understanding, the path of this keystore is what is needed for the configuration file for enterprise-search and the intermediary cert is what is used in the Kibana certificate authority config field (ca.pem). I have also tried to stuff both the signed and intermediate cert in the same .pem, as well as the private-key, signed and intermediate cert. Below are the relevant configurations:
kibana.yml
enterpriseSearch.host: https://ofuscated-dns:3002
enterpriseSearch.ssl.verificationMode: certificate
enterpriseSearch.ssl.certificateAuthorities:
- /path/ca.pem
enterprise-search.yml
ent_search.external_url: https://obfuscated-dns:3002
ent_search.listen_host: 0.0.0.0
ent_search.listen_port: 3002
ent_search.ssl.enabled: true
ent_search.ssl.keystore.path: "/path/keystore.jks"
ent_search.ssl.keystore.password: "pass"
ent_search.ssl.keystore.key_password: "pass"
I'm starting to feel like I fundamentally misunderstand something here. A lot of the jargon behind SSL/TLS certificates seems to lack standardization. While we are at it, what is a root cert in relation to what I have listed? Is it the intermediate cert? I see there is a master "root certificate" for the Digicert CN I certified under, however I'm unsure where this fits in. The config variable "certificateAuthorities" doesn't document what this .pem file should contain specifically and when searched the concept of a certificate authority is never associated with file contents, but instead is simply abstracted to the entity which provides certification (duh).
To put it succinctly: What does this variable "certificateAuthorities" explicitly entail?
UPDATE 09/28/2022
I have now confirmed that SSL is working when calling enterprise-search outside of the VM its running in. I can utilize its endpoint with my flutter and react app, however Kibana is till throwing the error mentioned above. I have checked that the root/intermediate CA provided to kibana's configuration is indeed the certificate linked with the signed cert provided to enterprise search and even confirmed so using SSLPoke.. This leaves me with the suspicion that perhaps Java is a bad actor in the mix? I've added the root/intermediate CA to the cacerts keystore in the ssl/java directory of the Linux VM, but still no luck. Any thoughts?
My company's project requires SSL certificates from our internal company domain. Typically what we do with these self-signed certificates is to export a certificate from a web browser (e.g. Chrome), then we import these certificates into a JVM truststore (cacerts) and we reference the path to this truststore when running a maven build. E.g. by passing the following argument:
-Djavax.net.ssl.trustStore=C:/Users/joebloggs/cacerts
Recently I found out that there is also an option for maven to allow self signed certificates if we set the following parameters:
-Dmaven.wagon.http.ssl.insecure=true
-Dmaven.wagon.http.ssl.allowall=true
I haven't asked anyone in my team why they don't use these the parameters above but I'm 100% sure this is related to security.
I would like to know if it is possible to let maven accept self-signed certificated but only from specific domains.
As an example, we have the following repositories:
primary-nexus.JoeBloggsCompany.com
secondary-nexus.JoeBloggsCompany.com
Is there a way for me to accept self-signed certificates only from the company domain (JoeBloggsCompany.com)?
Certificates are assigned to physical entities (persons or hosts). The host behind the domain JoeBloggsCompany.com is most probably the company's WWW-server.
See Maven Wagon HTTP, Features:
maven.wagon.http.ssl.allowall = true/false (false by default), whether to match the server's X.509 certificate against a requested IP/DNS name. If false/unset, a regular server check will be used, which means that the server's IP/DNS must match either the first CN, the Subject field or one of the Subject Alternative Name extension values (in case Subject or SAN type is either dNSName or iPAddress - see RFC 5280 for more details). Otherwise, no such matching will be applied.
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)
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.
our customer using Websphere 7 decided to no longer use the self-signed certificates, but from now on always use some CA certificates.
I was browsing via the Security guide for Websphere environment and SSL settings, and just found this information:
A CA client must be created to connect to the CA server before
creating a CA certificate. You need to implement the
com.ibm.wsspi.ssl.WSPKIClient interface to enable WebSphere
Application Server security to communicate with a remote CA. The class
name needs be provided as part of the CA client when it is created
I am not sure if I understand it correctly. But for the situation, where I already have some CA certificate, and I just want to import it onto our environment, do I need to implement this interface?
Does that mean, that if I need to switch from self-signed certificates on Websphere to CA certificate, our software needs some implementation change?
I would expect only importing new truststores, keystores etc. but no java implementation.
Does someone have the knowledge about this change?
But for the situation, where I already have some CA certificate, and I just want to import it onto our environment, do I need to implement this interface?
No, you don't need to implement this interface, you can just import your certificates into your environment (to trust and key stores).
This interface is required if you would like to have automatic management with remote CA e.g. if certificate expires to allow WAS to automatically connect to CA and request for new one.