I've recently created a PKCS keystore using LetsEncrypt and I configured my production profile for JHipster to run Tomcat on 8443 using the new keystore. I can get the application to run if I call "ciwiseaccounting.com:8443" but when the page arrives Chrome shows the "!" meaning the page is not secure. This is odd because I didn't see the SSL challenge occur. If I call "https://ciwiseaccounting.com:8443" this does not work. Does anyone know what I'm doing wrong? IPTables is wide open for now and I can nmap the 8443 listener. Here's my server config snippet:
server:
port: 8443
server.ssl.key-store:
/etc/letsencrypt/live/ciwiseaccounting.com/keystore.p12
server.ssl.key-store-password: password
server.ssl.keyStoreType: PKCS12
server.ssl.keyAlias: tomcat
You are using the server key twice in your configuration (line 1, then again on lines 3-6). This means the properties aren't parsed into the correct variables, resulting in regular http instead of https.
Try with the below config:
server:
port: 8443
ssl:
key-store: /etc/letsencrypt/live/ciwiseaccounting.com/keystore.p12
key-store-password: password
keyStoreType: PKCS12
keyAlias: tomcat
Related
Trying to get up SSL for prometheus (started via docker). I generated key and crt myself using open ssl. Pair: key and crt works ok.
when I execute this command on my host:
openssl s_server -cert prometheus.crt -key prometheus.key
It's saying "ACCEPT"
Here is my Dockerfile for prometheus container:
https://pastebin.com/4wGtCGp6
When I build image and start it, it's saying:
level=error ts=2021-09-24T20:44:11.649Z caller=stdlib.go:105 component=web caller="http: TLS handshake error from 127.0.0.1:50458" msg="remote error: tls: bad certificate"
кричит постоянно
In the web.yml I configure SSL in a following way:
tls_server_config:
cert_file: /etc/prometheus/prometheus.crt
key_file: /etc/prometheus/prometheus.key
In the prometheus.yml I configure SSL in a following way:
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
scheme: https
tls_config:
ca_file: /etc/prometheus/prometheus.crt
cert_file: /etc/prometheus/prometheus.crt
key_file: /etc/prometheus/prometheus.key
What could be the reason of this error ?
If it's self-signed, you shouldn't need a CA file, so try deleting that line in the tls_config and restarting the container.
I know this is old, so apologies if it's bad to answer an old question. Feel free to delete.
I try to enable ssl for Saltstack master and minion by following https://docs.saltstack.com/en/latest/ref/configuration/master.html#ssl But I am not sure how to verify it is using SSL.
I added this in master configuration:
ssl:
keyfile: /etc/salt/ssl/master/key.pem
certfile: /etc/salt/ssl/master/cert.pem
ssl_version: PROTOCOL_TLSv1_2
I added similar settings in minion. However, when I use openssl to test the port:
openssl s_client -connect <master ip>:4505 -debug and I get SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol. It seems the SSL is not enabled at all. How to verify if the SSL is enabled? The master and minion communication seems fine. I just to need to verify it is using SSL. I am on Centos 7 with python 2.7. Do I need to install any additional packages?
You also need to add
transport: tcp
Then you will at least get some SSL related error in /var/log/salt/master or /var/log/salt/minion
You can use tcpdump to capture some traffic and analyze it in wireshark to verify if the connection is ssl encrypted.
I used certbot to generate a Let's encrypt certificate for my website, but Yaws gives me an SSL accept failed: timeout error when I try to connect to it (after it times out of course). Interestingly it works when I redirect example.com to the local ip address of the server in the hosts file on my machine and connect to example.com:8080, but not when I connect to example.com without editing the hosts file or when I connect from my phone over 4G. Here's my webserver's configuration file (it is the only configuration file in conf.d):
<server www.example.com>
port = 8080
listen = 0.0.0.0
docroot = /usr/share/yaws
<ssl>
keyfile = /etc/letsencrypt/live/example.com/privkey.pem
certfile = /etc/letsencrypt/live/example.com/fullchain.pem
</ssl>
</server>
I made sure that the keyfile and the certificate are both readable by the yaws user. Next to the keyfiles is a README that contains the following:
`privkey.pem` : the private key for your certificate.
`fullchain.pem`: the certificate file used in most server software.
`chain.pem` : used for OCSP stapling in Nginx >=1.3.7.
`cert.pem` : will break many server configurations, and should not be used
without reading further documentation (see link below).
We recommend not moving these files. For more information, see the Certbot
User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates.
So I'm relatively sure I've used the right file (the other ones gave me errors like badmatch and {tls_alert,"decrypt error"}). I also tried trivial things like writing https:// before the URL, but it didn't fix the issue, also, everything works fine when the server is running without SSL. The version of Erlang running on my server is Erlang/OTP 19. Also, if it's unclear, the domain isn't actually example.com.
Also, example.com is redirected via cname to examplecom.duckdns.org, if that matters.
UPDATE:
My server was listening on port 8080, that was forwarded from the external port 80, for https connections, when the default https port is port 443. My other mistake was connecting to http://example.com instead of https://example.com. Forwarding the external port 443 to the internal port 8443 and configuring yaws to listen on port 8443 fixed everything.
Just to be sure to understand, when you do something like curl -v https://example.com:8080, you get a timeout, that's it ? (here https protocol and port 8080 are mandatory of course)
SSL timeout during accept can be triggered when an unencrypted request is received on a SSL vhost.
Could you also provide the output of the following command:
echo -e "HEAD / HTTP/1.0\r\n\r\n" | openssl s_client -connect mysite.com:8080 -ign_eof
And finally, which version of Yaws are you running ? on which OS ?
I am using Spring Boot generated with JHipster. I generated keystore using Java's keytool app. My .yml file looks like :
server:
port: 9090
ssl:
enabled: true
key-store: myKeystore.p12
key-store-password: ******
key-store-provider: SunJSSE
key-store-type: PKCS12
key-alias: tomcat
protocol: TLS
When I set enabled to false, server works on HTTP protocol, when I enable it getting no response from server for any endpoint using HTTP or HTTPS protocol.
It's because you used a certificate that is not trusted by a CA.
If you test with postman or any request simulator it will return 0Bytes.
If you test with a browser it will tell you that you must trust manually the certificate.
I am trying to setup gitlab on my server with SSL support. I am using a different port for the gitlab as follows in my nginx settings:
external_url 'https://myserver.com:2440
nginx['redirect_http_to_https'] = true
I also setup the SSL certificates as:
nginx['ssl_client_certificate'] = '/etc/ssl/AlphaSSLroot.crt'
nginx['ssl_certificate'] = '/etc/ssl/org.crt'
nginx['ssl_certificate_key'] = '/etc/ssl/org.key'
However, when I try to connect to my gitlab installation as https://myserver.com:2440, it comes back with the server refused to connect error. If I configure using http, it works.
I wonder if there is anything else I need to do to enable SSH here. I have my main website running on an apache web server using the same SSL certificate but on a completely different port (8080). So, I think I should be able to use the certificates.
It turns out that this was because of the passphrase and I had to remove that using
openssl rsa -in www.key -out new.key
and use the new.key in nginx.