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 am using server side CLI to get an SSL for my web app (following these instructions: https://github.com/dokku/dokku-letsencrypt).
After following the setup I ran:
root#taaalk:~# dokku letsencrypt taaalk
=====> Let's Encrypt taaalk
-----> Updating letsencrypt docker image...
0.1.0: Pulling from dokku/letsencrypt
Digest: sha256:af5f8529c407645e97821ad28eba328f4c59b83b2141334f899303c49fc07823
Status: Image is up to date for dokku/letsencrypt:0.1.0
docker.io/dokku/letsencrypt:0.1.0
Done updating
-----> Enabling ACME proxy for taaalk...
[ ok ] Reloading nginx configuration (via systemctl): nginx.service.
-----> Getting letsencrypt certificate for taaalk...
- Domain 'taaalk.taaalk.co'
darkhttpd/1.12, copyright (c) 2003-2016 Emil Mikulic.
listening on: http://0.0.0.0:80/
2020-04-28 23:12:10,728:INFO:__main__:1317: Generating new account key
2020-04-28 23:12:11,686:INFO:__main__:1343: By using simp_le, you implicitly agree to the CA's terms of service: https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
2020-04-28 23:12:12,017:INFO:__main__:1406: Generating new certificate private key
2020-04-28 23:12:14,753:ERROR:__main__:1388: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/4241725520
2020-04-28 23:12:14,757:INFO:__main__:396: Saving account_key.json
2020-04-28 23:12:14,758:INFO:__main__:396: Saving account_reg.json
Challenge validation has failed, see error log.
Debugging tips: -v improves output verbosity. Help is available under --help.
-----> Certificate retrieval failed!
-----> Disabling ACME proxy for taaalk...
[ ok ] Reloading nginx configuration (via systemctl): nginx.service.
done
root#taaalk:~#
So it's easier to read the error was:
2020-04-28 23:12:14,753:ERROR:__main__:1388: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/4241725520
I did a lot of googling around and the most promising post I found on the subject was this one:
https://veryjoe.com/tech/2019/07/06/HTTPS-dokku.html
In the post it suggested checking my Dokku domain misconfiguration and missing network listeners.
I ran dokku domains:report to check for the misconfiguration. This returned:
root#taaalk:~# dokku domains:report
=====> taaalk domains information
Domains app enabled: true
Domains app vhosts: taaalk.taaalk.co
Domains global enabled: true
Domains global vhosts: taaalk.co
And I then ran dokku network:report to check for missing listeners:
root#taaalk:~# dokku network:report
=====> taaalk network information
Network attach post create:
Network attach post deploy:
Network bind all interfaces: false
Network web listeners: 172.17.0.4:5000
After talking things through with a friend we tried adding an 'A' record to my DNS with the host 'taaalk.taaalk.co'.
I then ran:
root#taaalk:~# dokku letsencrypt taaalk
=====> Let's Encrypt taaalk
-----> Updating letsencrypt docker image...
0.1.0: Pulling from dokku/letsencrypt
Digest: sha256:af5f8529c407645e97821ad28eba328f4c59b83b2141334f899303c49fc07823
Status: Image is up to date for dokku/letsencrypt:0.1.0
docker.io/dokku/letsencrypt:0.1.0
Done updating
-----> Enabling ACME proxy for taaalk...
[ ok ] Reloading nginx configuration (via systemctl): nginx.service.
-----> Getting letsencrypt certificate for taaalk...
- Domain 'taaalk.taaalk.co'
darkhttpd/1.12, copyright (c) 2003-2016 Emil Mikulic.
listening on: http://0.0.0.0:80/
2020-04-30 13:39:58,623:INFO:__main__:1406: Generating new certificate private key
2020-04-30 13:40:03,879:INFO:__main__:396: Saving fullchain.pem
2020-04-30 13:40:03,880:INFO:__main__:396: Saving chain.pem
2020-04-30 13:40:03,880:INFO:__main__:396: Saving cert.pem
2020-04-30 13:40:03,880:INFO:__main__:396: Saving key.pem
-----> Certificate retrieved successfully.
-----> Installing let's encrypt certificates
-----> Unsetting DOKKU_PROXY_PORT
-----> Setting config vars
DOKKU_PROXY_PORT_MAP: http:80:5000
-----> Setting config vars
DOKKU_PROXY_PORT_MAP: http:80:5000 https:443:5000
-----> Configuring taaalk.taaalk.co...(using built-in template)
-----> Creating https nginx.conf
Enabling HSTS
Reloading nginx
-----> Configuring taaalk.taaalk.co...(using built-in template)
-----> Creating https nginx.conf
Enabling HSTS
Reloading nginx
-----> Disabling ACME proxy for taaalk...
[ ok ] Reloading nginx configuration (via systemctl): nginx.service.
done
Which was successful.
However, now taaalk.taaalk.co has an SSL, but taaalk.co does not.
I don't know where to go from here. I feel it makes sense to change the vhost from taaalk.taaalk.co to taaalk.co, but I am not sure if this is correct or how to do it. The Dokku documentation does not seem to cover changing the vhost name: http://dokku.viewdocs.io/dokku/configuration/domains/
Thank you for any help
Update
I changed the vhost to taaalk.co, so I now have:
root#taaalk:~# dokku domains:report
=====> taaalk domains information
Domains app enabled: true
Domains app vhosts: taaalk.co
Domains global enabled: true
Domains global vhosts: taaalk.co
However, I still get the following error:
root#taaalk:~# dokku letsencrypt taaalk
=====> Let's Encrypt taaalk
-----> Updating letsencrypt docker image...
0.1.0: Pulling from dokku/letsencrypt
Digest: sha256:af5f8529c407645e97821ad28eba328f4c59b83b2141334f899303c49fc07823
Status: Image is up to date for dokku/letsencrypt:0.1.0
docker.io/dokku/letsencrypt:0.1.0
Done updating
-----> Enabling ACME proxy for taaalk...
[ ok ] Reloading nginx configuration (via systemctl): nginx.service.
-----> Getting letsencrypt certificate for taaalk...
- Domain 'taaalk.co'
darkhttpd/1.12, copyright (c) 2003-2016 Emil Mikulic.
listening on: http://0.0.0.0:80/
2020-04-30 17:01:12,996:INFO:__main__:1406: Generating new certificate private key
2020-04-30 17:01:46,068:ERROR:__main__:1388: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/4277663330
Challenge validation has failed, see error log.
Debugging tips: -v improves output verbosity. Help is available under --help.
-----> Certificate retrieval failed!
-----> Disabling ACME proxy for taaalk...
[ ok ] Reloading nginx configuration (via systemctl): nginx.service.
done
root#taaalk:~#
Again, reproduced below for ease of reading:
2020-04-30 17:01:46,068:ERROR:__main__:1388: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/4277663330
Challenge validation has failed, see error log.
The fix was quite simple. First I made A records for both www. and root for my url pointing at my server.
I then set my vhosts to be both taaalk.co and www.taaalk.co with dokku domains:add taaalk www.taaalk.co, etc...
I then removed all the certs associated with taaalk.co with dokku certs:remove taaalk.
I then ran dokku letsencrypt taaalk and everything worked fine.
To anyone looking on who tried what Joshua did and still didn't get letsencrypt to generate certs:
My problem was that I didn't have any port mapping for port 80 on dokku, so letsencrypt was unable to communicate with the server to authorise the new cert, giving this error:
ERROR:__main__:1388: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/4277663330
Challenge validation has failed, see error log.
Silly me - I had removed the port http 80 mapping in dokku as I thought it was unnecessary.
To fix the problem I just added the port mapping again:
dokku proxy:ports-add myapp http:80:4000
(Note: my app connects to port 4000 hence above, your port may be different)
And then ran dokku letsencrypt:
dokku letsencrypt myapp
This sequence is important, setting the proxy ports correctly allows letsencrypt to connect and autorenew the TLS certs again.
I created a user in the Master.
First I created a key and certificate for him: dan.key and dan.crt
Then I created it inside Kubernetes:
kubectl config set-credentials dan \
--client-certificate=/tmp/dan.crt \
--client-key=/tmp/dan.key
This is the ~/.kube/config:
users:
- name: dan
user:
as-user-extra: {}
client-certificate: /tmp/dan.crt
client-key: /tmp/dan.key
I want to be able to run commands from a remote worker as the user I created.
I know how to do it with service account token:
kubectl --server=https://192.168.0.13:6443 --insecure-skip-tls-verify=true --token="<service_account_token>" get pods
I copied the certifiacte and the key to the remote worker and ran:
[workernode tmp]$ kubectl --server=https://192.168.0.13:6443 --client-certificate=/tmp/dan.crt --client-key=/tmp/dan.key get pods
Unable to connect to the server: x509: certificate signed by unknown authority
I followed this question:
kubectl unable to connect to server: x509: certificate signed by unknown authority
I tried like he wrote:
kubectl proxy --address 0.0.0.0 --accept-hosts '.*'
But I am still receiving:
Unable to connect to the server: x509: certificate signed by unknown authority
I copied the certifiacte and the key to the remote worker and ran:
[workernode tmp]$ kubectl --server=https://192.168.0.13:6443 --client-certificate=/tmp/dan.crt --client-key=/tmp/dan.key get pods
Unable to connect to the server: x509: certificate signed by unknown authority
You were missing the critical piece of data telling kubectl how to trust the https: part of that request, namely --certificate-authority=/path/to/kubernetes/ca.pem
You didn't encounter that error while using --token=... because of the --insecure-skip-tls-verify=true which you should definitely, definitely not do.
I tried like he wrote:
kubectl proxy --address 0.0.0.0 --accept-hosts '.*'
But I am still receiving:
You have followed the wrong piece of advice from whatever article you were reading; that --accept-hosts flag only controls the remote hostnames from which kubectl proxy will accept connections, and has zero to do with SSL anythings.
I'm attempting to set up Cryptpad via Docker, reachable through Traefik, on a public server. I have Traefik set up as well as Cryptpad but so far, upon navigating to http://cryptpad.myserver.com (which redirects to https, as specifically configured) I get a Bad Gateway error in the browser and the following error in the treafik container's logs:
level=warning msg="Error forwarding to https://172.19.0.2:3000, err: EOF"
Further, another issue which may be related is that it does not seem that Let's Encrypt is able to issue certs for neither cryptpad.myserver.com nor monitor.myserver.com (which I configured as per the instructions here https://www.digitalocean.com/community/tutorials/how-to-use-traefik-as-a-reverse-proxy-for-docker-containers-on-ubuntu-16-04).
EDIT:
The Bad Gateway issue does seem to be stemming from a failure to create a valid cert, as I can reach Cryptpad through Traefik fine over plain HTTP (after turning off the related HTTPS configurations of course). The title of this question has been edited accordingly to reflect this relation.
For example, when attempting to reach https://monitor.myserver.com, I get the following errors in the traefik container's logs:
time="2018-01-10T13:53:37Z" level=info msg="Server configuration reloaded on :9080"
time="2018-01-10T13:53:37Z" level=info msg="Server configuration reloaded on :9443"
time="2018-01-10T13:53:37Z" level=debug msg="LoadCertificateForDomains [monitor.myserver.com]..."
time="2018-01-10T13:53:37Z" level=debug msg="Look for provided certificate to validate [monitor.myserver.com]..."
time="2018-01-10T13:53:37Z" level=debug msg="No provided certificate found for domains [monitor.myserver.com], get ACME certificate."
time="2018-01-10T13:53:37Z" level=debug msg="Loading ACME certificates [monitor.myserver.com]..."
time="2018-01-10T13:53:37Z" level=warning msg="A new release has been found: 1.4.6. Please consider updating."
time="2018-01-10T13:53:37Z" level=error msg="map[monitor.myserver.com:[monitor.myserver.com] acme: Could not determine solvers]"
time="2018-01-10T13:53:37Z" level=error msg="Error getting ACME certificates [monitor.myserver.com] : Cannot obtain certificates map[monitor.myserver.com:[monitor.myserver.com] acme: Could not determine solvers]+v"
Similarly, when attempting to reach http://cryptpad.myserver.com, the following ssl errors are logged (ending with the EOF / Bad Gatewway error noted above):
time="2018-01-10T11:59:18Z" level=info msg="Server configuration reloaded on :9443"
time="2018-01-10T11:59:18Z" level=info msg="Server configuration reloaded on :9080"
time="2018-01-10T11:59:18Z" level=debug msg="LoadCertificateForDomains [cryptpad.myserver.com]..."
time="2018-01-10T11:59:18Z" level=debug msg="Look for provided certificate to validate [cryptpad.myserver.com]..."
time="2018-01-10T11:59:18Z" level=debug msg="No provided certificate found for domains [cryptpad.myserver.com], get ACME certificate."
time="2018-01-10T11:59:18Z" level=debug msg="Loading ACME certificates [cryptpad.myserver.com]..."
time="2018-01-10T11:59:18Z" level=error msg="map[cryptpad.myserver.com:[cryptpad.myserver.com] acme: Could not determine solvers]"
time="2018-01-10T11:59:18Z" level=error msg="Error getting ACME certificates [cryptpad.myserver.com] : Cannot obtain certificates map[cryptpad.myserver.com:[cryptpad.myserver.com] acme: Could not determine solvers]+v"
time="2018-01-10T11:59:52Z" level=debug msg="Look for provided certificate to validate [cryptpad.myserver.com]..."
time="2018-01-10T11:59:52Z" level=debug msg="No provided certificate found for domains [cryptpad.myserver.com], get ACME certificate."
time="2018-01-10T11:59:52Z" level=debug msg="Challenge GetCertificate cryptpad.myserver.com"
time="2018-01-10T11:59:52Z" level=debug msg="ACME got nothing cryptpad.myserver.com"
time="2018-01-10T11:59:52Z" level=debug msg="Look for provided certificate to validate [cryptpad.myserver.com]..."
time="2018-01-10T11:59:52Z" level=debug msg="No provided certificate found for domains [cryptpad.myserver.com], get ACME certificate."
time="2018-01-10T11:59:52Z" level=debug msg="Challenge GetCertificate cryptpad.myserver.com"
time="2018-01-10T11:59:52Z" level=debug msg="ACME got nothing cryptpad.myserver.com"
time="2018-01-10T11:59:52Z" level=warning msg="Error forwarding to https://172.19.0.2:3000, err: EOF"
The following is the docker-compose.yml file for Traefik and its traefik.toml file (both configured by consulting the guide already mentioned above [via Digital Ocean] and Traefik's own here https://docs.traefik.io/user-guide/docker-and-lets-encrypt/):
version: '2'
services:
traefik:
image: traefik
networks:
- proxy
ports:
- "9080:9080"
- "9443:9443"
- "8080:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /opt/traefik/traefik.toml:/traefik.toml
- /opt/traefik/acme.json:/acme.json
labels:
- "traefik.frontend.rule=Host:monitor.myserver.com"
- "traefik.port=8080"
container_name: traefik
networks:
proxy:
external: true
traefik.toml:
checkNewVersion = true
logLevel = "DEBUG"
defaultEntryPoints = ["http", "https"]
[entryPoints]
[entryPoints.http]
address = ":9080"
[entryPoints.http.redirect]
entryPoint = "https"
[entryPoints.https]
address = ":9443"
[entryPoints.https.tls]
[retry]
[acme]
email = "example#myserver.com"
storage = "acme.json"
entryPoint = "https"
onHostRule = true
onDemand = false
[web]
address = ":8080"
[docker]
endpoint = "unix:///var/run/docker.sock"
domain = "myserver.com"
watch = true
exposedbydefault = false
And here are the .env and docker-compose.yml files for Cryptpad, which I received and edited according to https://github.com/xwiki-labs/cryptpad/blob/master/docs/cryptpad-docker.md and the guides previously mentioned:
VERSION=latest
USE_SSL=true
STORAGE='./storage/file'
LOG_TO_STDOUT=true
docker-compose.yml
version: '2'
services:
cryptpad:
build:
context: .
args:
- VERSION=${VERSION}
image: "xwiki/cryptpad:${VERSION}"
hostname: cryptpad
labels:
- "traefik.backend=cryptpad"
- "traefik.docker.network=proxy"
- "traefik.frontend.rule=Host:cryptpad.myserver.com"
- "traefik.enable=true"
- "traefik.port=3000"
- "traefik.frontend.passHostHeader=true"
- "traefik.default.protocol=https"
environment:
- USE_SSL=${USE_SSL}
- STORAGE=${STORAGE}
- LOG_TO_STDOUT=${LOG_TO_STDOUT}
restart: always
volumes:
- ./data/files:/cryptpad/datastore:rw
- ./data/customize:/cryptpad/customize:rw
networks:
- proxy
- default
expose:
- "3000"
networks:
proxy:
external: true
Any help would be greatly appreciated. & of course I can provide much more details if necessary.
I think you are running into this issue:
https://community.letsencrypt.org/t/solution-client-with-the-currently-selected-authenticator-does-not-support-any-combination-of-challenges-that-will-satisfy-the-ca/49983
Apparently letsencrypt has disabled TLS-SNI-01 because of security issues. Here is the link to the issue: https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996
It looks like that letsencrypt needs a few days, before they can enable it again.
I have a UCC SSL certificate which holds up to 10 domain names and when I browse to a page using the certificate I get an ERR_CONNECTION_REFUSED error.
Here's what I've done:
Purchased a UCC certificate
Created a Heroku SSL endpoint
Uploaded the certificate: heroku certs:add server.crt server.key
Checked the certs: heroku certs:info
Info returns:
Fetching SSL Endpoint blah-1234.herokussl.com info for app-name... done
Certificate details:
Common Name(s):domain.com
www.domain.com
others......
Expires At: 2015-05-25 23:48 UTC
Issuer: /OU=Domain Control Validated/CN=www.domain.com
Starts At: 2014-05-25 23:48 UTC
Subject: /OU=Domain Control Validated/CN=www.domain.com
SSL certificate is verified by a root authority.
heroku certs
Gives:
Endpoint Common Name(s) Expires Trusted
------------------------ ------------------------------------------------------------------------------------------- -------------------- -------
blah-1234.herokussl.com www.domain.com, domain.com, .......... 2015-05-25 23:48 UTC True
- Updated the domain to point to blah-1234.herokussl.com
CName:
www blah-1234.herokussl.com TTL1hr
Waited TTL
Run a curl test: curl -kvI https://www.domain.com
Response:
* About to connect() to www.domain.com port 443 (#0)
* Trying 50.19.XXX.XXX...
* Connection refused
* Trying 54.204.XXX.XXX...
* Connection refused
* Trying 23.21.XXX.XXX...
* Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
The http urls work fine.
Any idea why this is happening? Is this because I'm using a UCC certificate?
The tech support guys at Heroku suggested removing and recreating the SSL end-point add-on and that solved the problem.
* Connection refused
These are no certificate errors, either your web server does not listen on port 443 or there is a firewall in between which is blocking connections.