I'm having the issue that my CNAME that points to a herokussl.com SSL endpoint refuses to resolve, or seemingly even be propagated by the DNS servers, but yet seems to work fine for the regular herokuapp.com name. I bought the domain name from whois.com, and their support claims the error is on heroku's end or my entering the url but I'm not so sure. My certificate seems fine. Tech details below, thanks for any and all help!
Details:
CNAMES:
deez.chrtwt.org -> sleepy-garden-8448.herokuapp.com Active **Works**
www.chrtwt.org -> gifu-3664.herokussl.com Active **Does not resolve**
pmarx$ heroku certs
Endpoint Common Name(s) Expires Trusted
----------------------- -------------- -------------------- -------
gifu-3664.herokussl.com www.chrtwt.org 2015-01-27 23:59 UTC True
pmarx$ heroku certs:info
Fetching SSL Endpoint gifu-3664.herokussl.com info for sleepy-garden-8448... done
Certificate details:
Common Name(s): www.chrtwt.org
Expires At: 2015-01-27 23:59 UTC
Issuer: /C=US/ST=Nevada/L=Las Vegas/O=Charitweet LLC/CN=www.chrtwt.org
Starts At: 2014-01-27 00:00 UTC
Subject: /C=US/ST=Nevada/L=Las Vegas/O=Charitweet LLC/CN=www.chrtwt.org
SSL certificate is verified by a root authority.
pmarx$ heroku domains
=== sleepy-garden-8448 Domain Names
deez.chrtwt.org
sleepy-garden-8448.herokuapp.com
www.chrtwt.org
www.pbridge.org
Related
I am running a vagrant box with Centos 7 as its OS. I installed blackfire without error and then tried to profile from the web browser. It started profile, but then just hung and hung and never finished. I then tried it via curl in the command line and got the following error:
$ blackfire curl https://gitlist.demo.blackfire.io/
Profiling: [####------------------------------------] 1/10
Error while running command: exit status 60
Use the option '--ignore-exit-status' to ignore command exit status
* About to connect() to gitlist.demo.blackfire.io port 443 (#0)
* Trying 54.76.137.79...
* Connected to gitlist.demo.blackfire.io (54.76.137.79) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* Server certificate:
* subject: CN=gitlist.demo.blackfire.io
* start date: Jul 07 14:09:16 2019 GMT
* expire date: Oct 05 14:09:16 2019 GMT
* common name: gitlist.demo.blackfire.io
* issuer: CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US
* NSS error -8181 (SEC_ERROR_EXPIRED_CERTIFICATE)
* Peer's Certificate has expired.
* Closing connection 0
curl: (60) Peer's Certificate has expired.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a
"bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Can someone explain to me what this error is? I have used Blackfire successfully on other projects (albeit, those were Ubuntu boxes) and have never seen this error. I can't find much on the web about this as well.
cURL is not sending the HTTP request because the "Peer's Certificate has expired".
As suggested, you could have added the "--insecure" option.
But it seems the certificate has been renewed.
On our build servers we use signtool.exe to sign our artifacts.
The same arguments are passed to signtool.exe each time, but it fails or passes sporadically due to our certificate not being used because of a "private key filter".
We have been using this process for a while but we started seeing failures the morning of March 27, 2019.
We start the signtool.exe process with the following arguments:
sign /fd sha256 /f "cert.p12" /p certPass /du hostSiteHere /v /debug /tr timeStampUrl "fileNames"
Specifications
- signtool.exe is from the windows 10 sdk
- build servers are hosted in AWS as windows 2016 server ec2 instances
- jenkins (v2.1.68) runs the builds using the amazon ec2 plugin (v1.42)
The logs, depending on if it passes or fails:
PASS
The following certificates were considered:
Issued to: myCompany, Inc.
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Wed Oct 30 12:00:00 2019
SHA1 hash: myCertSha1Hash
After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Private Key filter, 1 certs were left.
The following certificate was selected:
Issued to: myCompany, Inc.
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Wed Oct 30 12:00:00 2019
SHA1 hash: myCertSha1Hash
The following additional certificates will be attached:
Issued to: DigiCert SHA2 Assured ID Code Signing CA
Issued by: DigiCert Assured ID Root CA
Expires: Sun Oct 22 12:00:00 2028
SHA1 hash: digiCertSigningSha1Hash
Done Adding Additional Store
FAIL
The following certificates were considered:
Issued to: myCompany, Inc.
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Wed Oct 30 12:00:00 2019
SHA1 hash: myCertSha1Hash
After EKU filter, 1 certs were left.
After expiry filter, 1 certs were left.
After Private Key filter, 0 certs were left.
No certificates were found that met all the given criteria.
Odd behaviors to note:
the same ec2 instance can work successfully and then fail later
an ec2 instance failing may start working if a user RDPs into the ec2 instance
the same certificate, signtool.exe and arguments are being passed every time
I've some problems getting traefik to generate a lets-encrypt certificate for a domain with the www. supdomain as separate SAN. I have other containers with identical configuration working in this environment.
The (debug) log is quite verbose but I was able to see this messages
time="2018-08-27T07:41:43Z" level=debug msg="Try to challenge certificate for domain [mydomain.de www.mydomain.de] founded in Host rule"
time="2018-08-27T07:41:43Z" level=debug msg="Looking for provided certificate(s) to validate [\"mydomain.de\" \"www.mydomain.de\"]..."
time="2018-08-27T07:41:43Z" level=debug msg="Domains [\"mydomain.de\" \"www.mydomain.de\"] need ACME certificates generation for domains \"mydomain.de,www.mydomain.de\"."
time="2018-08-27T07:41:43Z" level=debug msg="Loading ACME certificates [mydomain.de www.mydomain.de]..."
time="2018-08-27T07:41:56Z" level=debug msg="Unable to split host and port: address www.mydomain.de: missing port in address. Fallback to request host."
time="2018-08-27T07:42:00Z" level=error msg="Unable to obtain ACME certificate for domains \"mydomain.de,www.mydomain.de\" detected thanks to rule \"Host:mydomain.de,www.mydomain.de\" : cannot obtain certificates: acme: Error -> One or more domains had a problem:\n[mydomain.de] acme: Error 403 - urn:ietf:paramsacme:error:unauthorized - Invalid response from http://mydomain.de/.well-known/acme-challenge/o74RJIDdodxG-hXpmX9en_55ZpptifsjYInrjY97Bic: \"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>300 Multiple Choices</title>\n</head><body>\n<h1>Multiple C\"\n"
time="2018-08-27T07:43:44Z" level=debug msg="No certificate provided dynamically can check the domain \"www.mydomain.de\", a per default certificate will be used."
The LABELs used by this container are:
LABEL traefik.enable="true" \
traefik.backend="mydomain-backend" \
traefik.docker.network="web-gateway" \
traefik.frontend.rule="Host:mydomain.de,www.mydomain.de" \
traefik.port="80"
So far the message is quite obvious with Invalid response from http://mydomain.de/.well-known/acme-challenge/o74RJIDdodxG-hXpmX9en_55ZpptifsjYInrjY97Bic which seems to return a code-300 result.
But why is this happening? Shouldnt' the traefik catch the requests to /.well-known and return the correct auth-key to letsencrypt?
Using only a single domain wwww.mydomain.de generation of certificate works.
How can I fix this?
Thanks in advance!
I found the solution. According to this this blog entry it is related to the DNS settings of the first domain mydomain.de which has a A-Record pointing to my server and an AAAA-Record (IPv6) pointing to a different location which caused the "Multiple choice" response which is in fact a response from the certbot/letsencrypt and is not related to traefik.
After removing the AAAA-Record from DNS certificate generations now seems to work.
I upgraded my Plan on Heroku to be able to use Heroku SSL, which includes Automated Certificate Management (ACM).
Hence when i run heroku certs:info I get:
Certificate details:
Common Name(s): www.myapp.fr
Expires At: 2018-04-29 10:10 UTC
Issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Starts At: 2018-01-29 10:10 UTC
Subject: /CN=www.myapp.fr
SSL certificate is verified by a root authority.
or heroku certs:
Name Common Name(s) Expires Trusted Type
────────────────── ──────────────── ──────────────────── ─────── ────
tyrannosaurs-12099 www.myapp.fr 2018-04-29 10:10 UTC True ACM
However, my app still appears as being unsecured (no https) and when I run curl -kvI https://www.myapp.fr, here is what I get:
[2.3.4]
* Rebuilt URL to: https://www.myapp.fr/
* Trying 79.125.111.38...
* Connected to www.myapp.fr (79.125.111.38) port 443 (#0)
* Unknown SSL protocol error in connection to www.myapp.fr:-9838
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to www.myapp.fr:-9838
Any idea on How can I get my HTTPS working ?
I think I solved it at that time doing this: In order to force all clients to use https you will need to update your application to check for this. In Rails this is usually done by setting
config.force_ssl = true
in config/environments/production.rb.
Then wait a few minutes and it should be OK.
Here's my situation:
I'm using Elastic Beanstalk to spin up a single EC2 instance without an ELB. I want to have the instance only accessible through the API Gateway. So, I went the route of using client-side certificates for authentication, like what's described here.
My EC2 instance has Nginx serving a Rails application. I generated a self-signed certificate on my machine and configured Nginx to use that to serve stuff over https.
Everything seems fine, but when I try to invoke my proxy endpoint from the API Gateway console, I get a 500 error like below:
...
Thu Sep 14 02:27:05 UTC 2017 : Endpoint request URI: https://xxxxxxxxx.xxxxxxxxx.us-east-1.elasticbeanstalk.com/health
Thu Sep 14 02:27:05 UTC 2017 : Endpoint request headers: {x-amzn-apigateway-api-id=xxxxxxxxx, User-Agent=AmazonAPIGateway_xxxxxxxx, Accept-Encoding=identity}
Thu Sep 14 02:27:05 UTC 2017 : Endpoint request body after transformations:
Thu Sep 14 02:27:05 UTC 2017 : Sending request to https://xxxxxxxxx.xxxxxxxx.us-east-1.elasticbeanstalk.com/health
Thu Sep 14 02:27:05 UTC 2017 : Execution failed due to configuration error: General SSLEngine problem
Thu Sep 14 02:27:05 UTC 2017 : Method completed with status: 500
I'm thinking that it has something to do with the fact that I'm using a self-signed certificate on the backend. But do I really have to purchase a legitimate certificate in order to complete my setup? Are there any other solutions that would allow me to only accept requests to my EC2 instance only through the API Gateway?
I looked at the Lambda method that is described here, but I didn't want to add any more complexity or latency to the requests.
Here's my Nginx configuration for completeness:
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_prefer_server_ciphers on;
ssl_client_certificate /etc/pki/tls/certs/api_gateway.cer;
ssl_verify_client on;
if ($ssl_protocol = "") {
return 444;
}
}
see my answer here AWS API Gateway - Use Client-Side SSL Certificates. Sot sure what incompatibility is with NGINX - i managed to create PoC and validate Authenticate with Client-SSL behavior
It appears at the time of this writing that API Gateway has a known incompatibility with NGINX around Client Certificates.