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.
Related
We are trying to establish a grpcs (TLS) connection between a docker container running API server (based on Node.js) and another docker container running peer0 from Fabric network.
All containers are orchestated by docker swarm, and both containers happen to be running on the same Linux host.
The error log thrown by API container is the following:
2021-01-07T18:27:38.110Z - error: [Remote.js]: Error: Failed to
connect before the deadline URL:grpcs://10.0.1.2:9051 Query has
completed, checking results error from query = { Error: Failed to
connect before the deadline URL:grpcs://10.0.1.2:9051
at checkState (/usr/src/app/node_modules/grpc/src/client.js:833:16) connectFailed:
true } sampleEvent ERROR : Error: 14 UNAVAILABLE: Connect Failed E0107
18:27:53.602719124 16 ssl_transport_security.cc:1229] Handshake
failed with fatal error SSL_ERROR_SSL: error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed.
And the error log thrown from peer0 is:
2021-01-07 18:50:22.224 UTC [core.comm] ServerHandshake -> ERRO 043 TLS handshake failed with error EOF server=PeerServer remoteaddress=10.0.1.4:46212
IP addresses layout
IP address for API container is 10.0.1.94
IP address for peer0 container is 10.0.1.3
virtual IP address for docker service peer0 is 10.0.1.2
IP address for docker swarm load balancer endpoint is 10.0.1.4
Any suggestion of where to further troubleshoot? At this point is not clear if the problem is with the docker swarm internal networking, or an issue with ssl certificates in either side of the network.
UPDATE Feb 2 2021
The original TLS handshake error was fixed by upgrading the javascript used in NodeSDK. Among other things we started using the addToWallet.js script contained in the commercial-paper example
After being able to stablish TLS succesfully between Node.js API and peer0, we get a new access denied error when making a simple query to chaincode_example02
Facts:
We are running the query with 2 Admin users
One Admin is first-network original Admin#org1.example.com, with credentials generated by cryptogen tool
The other Admin is Admin#buyer.dlt.com whose credentials were created with openssl and a self signed in-company CA
From CLI, both Admin are good and are allowed to run peer commands interchangeably
From Node.js app, only Admin#org1.example.com is allowed to run queries. The message printed to console.log is:
Transaction has been evaluated, result is: 100
When running queries with Admin#buyer.dlt.com we get the following error logs:
Error logs from peer0#buyer.dlt.com
2021-02-02T04:08:45.291086617Z ^[[36m2021-02-02 04:08:45.290 UTC [protoutils] checkSignatureFromCreator -> DEBU 6e637^[[0m creator is &{BuyerMSP 8b7cc2ee996be4f7e5dbb1a4f64db67afd2ff8a2f41276c9bd7f33a2447dd9df}
2021-02-02T04:08:45.291094817Z ^[[36m2021-02-02 04:08:45.290 UTC [protoutils] checkSignatureFromCreator -> DEBU 6e638^[[0m creator is valid
2021-02-02T04:08:45.291100418Z ^[[36m2021-02-02 04:08:45.290 UTC [msp.identity] 2021-02-02T04:08:45.303821799Z ^[[33m2021-02-02 04:08:45.303 UTC [protoutils] ValidateProposalMessage -> WARN 6e63b^[[0m channel [mychannel]: creator's signature over the proposal is not valid: The signature is invalid
2021-02-02T04:08:45.303891604Z ^[[36m2021-02-02 04:08:45.303 UTC [endorser] func1 -> DEBU 6e63c^[[0m Exit: request from 10.0.1.84:52696
2021-02-02T04:08:45.303902005Z ^[[34m2021-02-02 04:08:45.303 UTC [comm.grpc.server] 1 -> INFO 6e63d^[[0m unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=10.0.1.84:52696 error="access denied: channel [mychannel] creator org [BuyerMSP]" grpc.code=Unknown grpc.call_duration=13.783655ms
Error log on console.log from script query.js:
2021-02-02T04:08:45.305Z - error: [Channel.js]: Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [BuyerMSP]
2021-02-02T04:08:45.307Z - error: [Network]: _initializeInternalChannel: Unable to initialize channel. Attempted to contact 1 Peers. Last error was Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [BuyerMSP]
Failed to evaluate transaction: Error: Unable to initialize channel. Attempted to contact 1 Peers. Last error was Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [BuyerMSP]
In the end, this issue turned out to be two issues, in a 'russian doll like' style.
1. First issue: TLS Handshake error
This was fixed by upgrading the SDK library to the latest release
2. Second issue: Node SDK query triggers error "The signature is invalid".
The reason turned out to be that the CLI (written on Go) is using the Go crypto support which allows it to generate a signature from a hash without any knowledge of the curve used for the key. Instead, the SDK libraries used by the Node implementation require a specific curve to be specified by the code generating the signature, separately from the private key itself.
Bottom line, private keys used within Node SDK should be P-256.
As an alternative, as suggested by hyperledger dev team:
If you really must use a curve other than P-256 then you might be able
to use one of the following approaches:
-Use the off-line signing approach included in the documentation but specify an alternative curve instead of 'p256'. The supported curves
for the elliptic package documented here:
https://github.com/indutny/elliptic
-Set your own CryptoSuite implementation on the Client that underpins the Gateway object, with your own CryptoSuite.sign() implementation:
https://hyperledger.github.io/fabric-sdk-node/release-2.2/CryptoSuite.html#sign
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.
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.
I am trying create a channel according to documentation
Hyperledger Fabric v1.0 docs
Have an issue with certificate. On the docker "hyperledger/fabric-tools" node I can find certificate with current name - tlsca.example.com. But the channel cannot be created. I have certificate hand shake issue. Should I check/mount certificate to the peer node ?
root#4b6423da537b:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com# peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
2017-07-27 16:49:58.949 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-07-27 16:49:58.949 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-07-27 16:49:58.954 UTC [grpc] Printf -> DEBU 003 Failed to dial orderer.example.com:7050: connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"tlsca.example.com\")"; please retry.
Error: Error connecting due to rpc error: code = Internal desc = connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"tlsca.example.com\")"
Usage:
Thanks.
i meet the same problem. And run this command to close the network.
./network_setup.sh down mychannel
The reason that cause my problem is that the source code exists a error. So i modify this code error and reopen the network. This problem work out.
It would seem that you are in the incorrect working directory. When running the sample manually, you start the cli container and it places you in the /opt/gopath/src/github.com/hyperledger/fabric/peer directory. That is where you should be running the peer command. It would seem from your post that you were running the peer command in the /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com directory in the container, and it is not finding the configuration files that were mounted for the example.
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