I'm now researching the Hashistack and trying to deploy pet microservice-based project on it. I deployed Nomad and Consul clusters with Ansible roles on bare metal nodes:
https://github.com/ansible-community/ansible-consul.git (v2.5.4)
https://github.com/ansible-community/ansible-nomad.git (v1.9.6)
Servers of Nomad and Consul are placed on the same nodes.
I do not use Vault. I created separate private CA, generated TLS certificates and private keys for these services and configured Nomad and Consul servers and clients to use them.
My goal is to setup production ready Hashistack cluster. So that I want to setup full TLS for both services.
I successfully connected to both UIs via HTTP, but when I try HTTPS, I get the SSL_ERROR_BAD_CERT_ALERT error.
I'll appreciate if you suggest the best practices to operate the Hashistack in production, and what steps are required for it.
Thank you!
I'm a bit late to respond, but came across the same error. Figured I'd leave my solution in case future readers find it helpful...
For me, the issue came down to the verify_https_client flag in my Nomad tls config block. Since Nomad is configured for mutual TLS, all clients (including web browsers) need to provide a client certificate signed by the same CA used by Nomad in order to connect. You'll need to generate/sign that certificate, and look up how to configure your browser to automatically provide it when needed.
For production use, that's the safest route. For a dev environment, you can just set that verify_https_client config to false in your Nomad config.
Here's a link to the Nomad docs for this flag: https://www.nomadproject.io/docs/configuration/tls#verify_https_client
You need first, generate a client certificate for your web brower.
Then convert it to PKCS12 format.
openssl pkcs12 -export -inkey ./nomad-cli.key -in ./nomad-cli.pem -out ./nomad-cli.p12
Let's say your are using Chrome,
Go to chrome://settings/certificates?search=certificate and import the converted certificate nomad-cli.p12.
I've found answer for same case.
When nomad cluster deployed with mTLS need deploy cli keys to each server nodes or at least on the node to which you are configuring the connection.
cli keys generated by instruction https://learn.hashicorp.com/tutorials/nomad/security-enable-tls#nomad-ca-key-pem
and nginx configured by instruction https://learn.hashicorp.com/tutorials/nomad/reverse-proxy-ui?in=nomad/manage-clusters
however this manual does not contain a description of configuring mTLS.
You need add following parameters in location /.
location / {
....
proxy_pass https://127.0.0.1:4646;
proxy_ssl_certificate /etc/nomad.d/cli.pem;
proxy_ssl_certificate_key /etc/nomad.d/cli-key.pem;
proxy_ssl_verify off;
....
}
In this case nginx can connect encrypted connection with nomad http port with TLS.
Also don't forget enable http basic auth at least.
Related
When i build the container of elasticsearch and the compose logs I got "WARN", "message":"received plaintext http traffic on an https channel, closing connection Netty4HttpChannel{localAddress=/172.29.0.2:9200, remoteAddress=/172.29.0.4:54642}"
And also when I curl to "https://elasticsearch:9200" i got the following curl: (60) SSL certificate problem: self signed certificate in certificate chain It might be the problem from the SSL certificate?
I have a privekey.pem and fullchain.pem files how to use them in order to solve this issue ?
Noting it is all up but kibana not connected to elasticsearch, and also i tried to disable security but i have the same error.
Unless you are using a trial license, Elastic Stack security features require SSL/TLS encryption for the transport networking layer.
This section demonstrates an easy path to get started with SSL/TLS for both HTTPS and transport using the Elasticsearch Docker image. The example uses Docker Compose to manage the containers.
Im new to the topic of SSL certificates and i want to install my purchased SSL so that when users enter my site they wont see the untrusted certificate waring here are the steps i did so far
created a p12 file using the keytool
created a csr file from the file in step 1
uploaded the csr to my ssl vendor and after passing their verification of my domain, downloading the following files: .crt, .ca-bundle, .p7b files
i placed all the files (including the generated file by me) in the resources directory and added the following properties
server.ssl.key-store:classpath:myFile.p12
server.ssl.key-store-password:some_pass
server.ssl.keyStoreType:PKCS12
server.ssl.keyAlias:someAlias
i later ran the following command: keytool -importcert - trying to import the file i got from the ssl vendor to the file i created (.p12)
than i created my jar and uploaded it to pivotal cloud foundry but i still see the invalid certificate message
i dont know if i need to do something on the pivotal platform or something on the spring boot config
The only way this would work is if you use a TCP route. With standard HTTP routes on Cloud Foundry, the traffic first hits a load balancer & then Gorouter. TLS termination is going to happen there, not at your application. If you use a TCP route, this will load balance at the TCP level and allow your application to perform the TLS termination directly.
That said, you really don't want to do that. the TCP route isn't likely to allow you to pick port 443, because a port can only be assigned to one application. That means only one application using TCP routes can have port 443. Also in most cases, platform operators are only allowing high numbered ports for TCP routes, which means no one would be able to pick 443. Long story short, you don't want your users to have to access your site as https://www.example.com:47385, so you don't want a TCP route.
To set this up properly with standard HTTP routes, you are going to need to work with your platform operations team. Together you will need to do the following:
Obtain the domain you'd like to use.
Obtain a load balancer. This needs to be configured to route traffic to the Gorouters in the foundation. You can skip this and use the existing load balancer, but that has implications[1] for step #6 below.
Configure DNS for your domain so that it routes to the load balancer in step #2.
Add the domain as a private or shared domain in CF.
Map a route to your application using the domain you created in step #3.
Add your TLS certificate & key to the load balancer [1].
When you've done all this, traffic to your domain will resolve to the IPs of your load balancers. Your user's browser will make an HTTPS request to the LB, which will terminate TLS (if it's an HTTP/layer-7 LB), and forward along to Gorouter (if there is a TCP/layer-4 LB, then TLS is terminated here), which in turn forwards along to your application (based on the route you mapped).
Your application will need to look at the x-forwarded-for and x-forwarded-proto headers to confirm if the request came in over HTTPS, since it is not terminating TLS directly.
[1] - The implication is with how the certificates get installed. With a separate LB, you add the cert to it and are done. If you are trying to reuse the platform LB, you will need to add the cert to the existing list of certs. In addition, if your platform operations team is using a TCP/layer-4 load balancer then TLS termination does not happen at the LB, it happens at Gorouter. This means you then have to load your TLS cert into the Gorouter, which requires a Bosh deploy and is more work. Modifying the platform LB also runs the risk of an error taking down the foundation. For those reasons and more, adding a separate LB for your app is usually the way to go.
Using Fabric 2 stateless services with Kestrel 3.1
Have a problem exposing a HTTPS endpoint. A primary certificate is defined on the cluster (Security section). This certificate (primary) is accessible to the nodes (i.e. via X509Store find operations on the thumbprint or subject) automatically by Service Fabric. When configuring kestrel for a particular endpoint the certificate is used by the UseHttps method on any Ipv6 address (i.e. Ipv6Any). In the Application Manifest the access to the certificate's private key is granted (see article) with an endpoint policy. Here is example code on gist. The cluster's load balanser exposes the 443 HTTPS endpoint via the 8443 port (similar to the setup in this tutorial).
Despite the above configuration when navigating to the application the response is that the web page is either down or has been moved plus a ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY error.
The service according to the logging sent to Insights starts fine using the primary certificate:
Hosting environment: Production
...
Now listening on: https://[::]:443
Anybody else get as similar setup working?
Turns out I had set the protocol to HTTP2 rather than HTTP1.
Is it possible to generate certificates via Citadel for HTTPS services? In my case, I would like to use the Elastic ECK operator to spawn a new Elasticsearch cluster + Kibana, but I don't want to use the self-signed CA (since I'd have to push that CA certificate file to all and every service that wants to connect to the ES API); rather I'd like to use another self-signed certificate authority; the one and the same that Istio uses.
My hope is that if we get around to adding Vault to the cluster + cert-manager, I can easily create new certificates with that and all HTTPS usage INSIDE the cluster.
How can I (or can I), generate TLS certificates with Istio somehow? I have SDS installed in the cluster.
This question is not about:
How to generate public certificates
cert-manager
How to turn off TLS in Elasticsearch's HTTP endpoint
I need to install VeriSign SSL certs on a Heroku app.
The requirements for using these certs are:
Dedicated IP address.
A CSR generated on the web server with the domain name.
Is it possible to achieve the above, either directly through the Heroku platform or via custom addons.
You should follow the Heroku SSL Endpoint Guide. Don't worry about the IP address, it comes courtesy of the Heroku SSL endpoint. I also don't think you need to create the certificate signing request on the server, once the certificate is created, you can use it where you want.