dsnezhkov / racketeer

MIT License
68 stars 22 forks source link

requirements for TLS certificate #5

Open wimdecorte opened 2 years ago

wimdecorte commented 2 years ago

I have Racketeer server working as long as I keep the listening address to 127.0.0.1. But since that make it listen to outside requests I'm trying have it listen to an FQDN.

This is the error I get

image

with either self-signed cert for the FQND or with a Let's Encrypt cert for that same domain. For the LE cert I converted it from pem to crt since that's what the example uses.

What does the error mean?

Relevant modified code: image

I also tried with the TLS flag off to force HTTP but I'm getting the same error on that too.

Feels like I'm getting close to make this work...

dsnezhkov commented 2 years ago

I would suggest checking fo reverse DNS resolution for the domain and making sure that the IP it resolves to is what the -H points to (e.g. if you are in NAT -then you would need to listen to internal network IP and forward from external appropriately). There are no overly complex requirements for the cert, see dist/gencert.sh for an example. Also, do check if you can actually find the certs and the private key in ./keys directory adjacent to the running executable. It is possible that you may need ./keys at that level at build time due to go:embed keys/*.

Alternatively to punching NAT you may potentially keep running the server on 127.0.0.1 and just forward the requests to that via something like NGINX/Apache, stunnel, etc.

wimdecorte commented 2 years ago

DNS resolves properly since I'm using the FQDN to ssh in and also from VS Code. I guess I can use an ngrok tunnel as an alternative but then I wouldn't have the keys.

I did check out gencert,sh and modified it so that the CN uses the FQDN. And I copied the server.crt and server.key over to the proper keys folder.

I'm using "go run main.go" to run server so the keys folder is the one off the server folder of the repo. and the certs there are the ones produced by the gencert.sh script

image

so what does the error indicate? That it can't find the certs? That the certs are invalid?

wimdecorte commented 2 years ago

Also, certbot worked with the FQDN so that also indicates that the DNS resolves properly.

dsnezhkov commented 2 years ago

The error is an internal go/http HTTPS error code. It mostly means it cannot listen on that IP/Port and if TLS possibly cannot find the cert/key, at least in my testing. I have added a more verbose error message but it will just tell you of the same. Try yo build and exe by go build main.go instead of go run main.go which will ensure you embed the keys in the exe. My run :

~/Code/racketeer/server (main) $ ls
dist    go.mod  go.sum  help    keys    main.go man     routers serve   surveys types   utils
~/Code/racketeer/server (main) $ ls keys/
server.crt server.key
~/Code/racketeer/server (main) $ go version
go version go1.17.1 darwin/amd64
dimas@tibet ~/Code/racketeer/server (main) $ go build -o server main.go
~/Code/racketeer/server (main) $ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    inet 192.168.88.7 netmask 0xffffff00 broadcast 192.168.88.255
    status: active
~/Code/racketeer/server (main) $ ./serve -H 192.168.88.7 -P 3000 -s
bash: ./serve: is a directory
dimas@tibet ~/Code/racketeer/server (main) $ ./server -H 192.168.88.7 -P 3000 -s

  ____    _   _   ____
 |  _ \  | \ | | / ___|
 | |_) | |  \| | \___ \
 |  _ <  | |\  |  ___) |
 |_| \_\ |_| \_| |____/
 v0.5 Full Metal Jacket

Starting HTTP/S Server - 192.168.88.7:3000
no agent:
dsnezhkov commented 2 years ago

One thing I would add is that crypto/tls wants a PEM formatted certs. So I think if you are utilizing the cert from LetsEncryot - you would want the sever to get the equivalent of:

http.ListenAndServeTLS(
":443",
 "/etc/letsencrypt/live/www.yourdomain.com/fullchain.pem", 
"/etc/letsencrypt/live/www.yourdomain.com/privkey.pem", 
nil)
wimdecorte commented 2 years ago

you mentioned to the go embed keys before, in the code, it's disabled though, is that relevant?

image

dsnezhkov commented 2 years ago

No, these are go compiler directives, not comments. See: https://pkg.go.dev/embed