Closed KodySalak closed 1 year ago
gregtwallace
commented
1 year ago I am a bit surprised as Go generally compiles everything it needs into the binary. However, the project uses CGO (thanks SQLite) so I suspect that's causing an external dependency. Try upgrading libc6 package. I checked my server and it is currently running version 2.35 of this package. Please let me know if that corrects the issue.
If it does, I'll revise some notes for the pre-req.
KodySalak
commented
1 year ago I couldn't get 20.04 to take the update libc, so I upgraded to Ubuntu 22.04. I got the app working (woohoo!), but I am running into this error when trying to get the app to use my certs I generated from my internal Windows CA (the hostname for this vm is certhub.mydomain.local).
May 2 00:14:35 certhub lego-linux-amd64[58371]: 2023-05-02T00:14:35.840-0500#011error#011app/run.go:278#011failed to configure https cert: no such record found in storage
I have the permissions correct for the files and have the following in the config.yaml:
# API Server's key and cert
# These names should match the 'name' field of the desired key and cert within
# the application.
# If not specified (or invalid), a self-signed cert is created on each launch
# until proper values are specified.
private_key_name: privkey.key
certificate_name: cert.crtI have the cert and the privkey there:
-rw-r--r-- 1 legocerthub legocerthub 2269 May 1 23:16 cert.crt
-rw-r----- 1 legocerthub legocerthub 3145 May 1 22:27 CHANGELOG.md
-rw-r----- 1 legocerthub legocerthub 2917 May 1 22:27 config.default.yaml
-rw-r----- 1 legocerthub legocerthub 2899 May 2 00:14 config.yaml
drwxr-xr-x 3 legocerthub legocerthub 4096 May 2 00:14 frontend_build/
-rw-r--r-- 1 legocerthub legocerthub 86016 May 1 22:27 lego-certhub.db
-rwxr-x--- 1 legocerthub legocerthub 17926016 May 1 22:27 lego-linux-amd64*
-rw-r----- 1 legocerthub legocerthub 902 May 1 22:27 LICENSE.md
drwxr--r-- 2 legocerthub legocerthub 4096 May 1 22:27 log/
-rw------- 1 legocerthub legocerthub 1704 May 1 23:14 privkey.key
-rw-r----- 1 legocerthub legocerthub 306 May 1 22:27 README.md
drwxr-xr-x 2 legocerthub legocerthub 4096 May 1 22:36 scripts/Any ideas? Or am I not doing the right thing?
gregtwallace
commented
1 year ago The private_key_name and certificate_name refer to a key and cert within the app database, not a path. That is, import or generate a key for the app to use, setup a LE account, and then issue a certificate. Once issued, update the fields to the name of the key and cert and restart and you'll be good to go.
KodySalak
commented
1 year ago I think I'm 🤏this close to getting this to work. New to ACME and LE, apologies.
I set up an account and got it registered with ACME. I tried to make a certhub.mydomain.com certificate using dns-01 (cloudflare). I see the TXT records going in, and it's propigating, but when the check comes back (after setting the logging to debug), I get the following error:
May 2 19:04:14 certhub lego-linux-amd64[2891]: 2023-05-02T19:04:14.341-0500#011debug#011acme/post_signed.go:113#011acme response status code: 200
May 2 19:04:14 certhub lego-linux-amd64[2891]: 2023-05-02T19:04:14.341-0500#011debug#011acme/post_signed.go:122#011{
May 2 19:04:14 certhub lego-linux-amd64[2891]: "status": "invalid",
May 2 19:04:14 certhub lego-linux-amd64[2891]: "expires": "2023-05-10T00:03:42Z",
May 2 19:04:14 certhub lego-linux-amd64[2891]: "identifiers": [
May 2 19:04:14 certhub lego-linux-amd64[2891]: {
May 2 19:04:14 certhub lego-linux-amd64[2891]: "type": "dns",
May 2 19:04:14 certhub lego-linux-amd64[2891]: "value": "certhub.mydomain.com"
May 2 19:04:14 certhub lego-linux-amd64[2891]: },
May 2 19:04:14 certhub lego-linux-amd64[2891]: {
May 2 19:04:14 certhub lego-linux-amd64[2891]: "type": "dns",
May 2 19:04:14 certhub lego-linux-amd64[2891]: "value": "mydomain.com"
May 2 19:04:14 certhub lego-linux-amd64[2891]: }
May 2 19:04:14 certhub lego-linux-amd64[2891]: ],
May 2 19:04:14 certhub lego-linux-amd64[2891]: "authorizations": [
May 2 19:04:14 certhub lego-linux-amd64[2891]: "https://acme-v02.api.letsencrypt.org/acme/authz-v3/000000000000",
May 2 19:04:14 certhub lego-linux-amd64[2891]: "https://acme-v02.api.letsencrypt.org/acme/authz-v3/000000000000"
May 2 19:04:14 certhub lego-linux-amd64[2891]: ],
May 2 19:04:14 certhub lego-linux-amd64[2891]: "finalize": "https://acme-v02.api.letsencrypt.org/acme/finalize/0000000000/000000000000"
May 2 19:04:14 certhub lego-linux-amd64[2891]: }
May 2 19:04:14 certhub lego-linux-amd64[2891]: 2023-05-02T19:04:14.341-0500#011debug#011orders/worker.go:204#011order status invalid; acme error: <nil>
May 2 19:04:14 certhub lego-linux-amd64[2891]: 2023-05-02T19:04:14.348-0500#011debug#011orders/worker.go:31#011worker 1: end of high priority order fulfiller (orderId: 5)I get a "status invalid; acme error:
I zero'd out my account in the log above.
gregtwallace
commented
1 year ago This doesn't tell me enough to help you. I'd need to see more of the log. Invalid status just means the order failed somewhere. The order likely failed because one or both of the authz failed (which should be somewhere in the log). Authz validate when their respective challenge succeeds. The challenges should also be logged.
edit: https://datatracker.ietf.org/doc/html/rfc8555 section 7.1.6 has good diagrams showing the flow of various records to help you understand what is happening.
Verify cloudflare is setup correctly. A log line should be: dns01cloudflare/service.go:62, dns01cloudflare configured domains: [gtw86.com] Your domain(s) should be showing in the brackets.
What is your config.yaml for dns checker?
(sample snipet) challenges: dns_checker:
# sleeps for the specified number of seconds and then assumes the record
# is fully propagated
skip_check_wait_seconds: null
# services to use if checker is not disabled
dns_services:
# generally you do NOT want these to be internal dns servers
# internal dns usually has long cache and doesn't truly check propagation
# if you don't want external dns checking, use skip_check above
- primary_ip: 1.1.1.1
secondary_ip: 1.0.0.1
- primary_ip: 9.9.9.9
secondary_ip: 149.112.112.112
- primary_ip: 8.8.8.8
secondary_ip: 8.8.4.4If you want to send me the whole log I can probably tell you what the problem is.
KodySalak
commented
1 year ago Just sent you the log.
# Challenge Providers
challenges:
dns_checker:
# specifying skip check wait disables dns record validation and instead
# sleeps for the specified number of seconds and then assumes the record
# is fully propagated
skip_check_wait_seconds: null
# services to use if checker is not disabled
dns_services:
# generally you do NOT want these to be internal dns servers
# internal dns usually has long cache and doesn't truly check propagation
# if you don't want external dns checking, use skip_check above
- primary_ip: 1.1.1.1
secondary_ip: 1.0.0.1
- primary_ip: 9.9.9.9
secondary_ip: 149.112.112.112
- primary_ip: 8.8.8.8
secondary_ip: 8.8.4.4
providers:
# http-01 internal server
http_01_internal:
enable: false
# port to run the http challenge server on
port: 4060
# dns-01 using scripts that are external to LeGo
dns_01_manual:
enable: false
create_script: ./scripts/create-dns.sh
delete_script: ./scripts/delete-dns.sh
# dns-01 via LeGo Cloudflare integration
dns_01_cloudflare:
enable: true
accounts:
- email: cloudflare@mydomain.com
global_api_key: %%My_Global_API_Key%%
tokens:
- email: cloudflare@mydomain.com
- api_token: %%My_Domain_API_Token%%
zone_names:
- domain1.comResolved.
See: https://github.com/gregtwallace/legocerthub-backend/issues/1
Hi. Like the concept! When I try to install this on Ubuntu 20.04, I get the following errors:
If I install it as a service with the provided script, I see this:
Looking in
/var/log/syslog, I see this:I was digging more into this, and I found that 20.04 ships with 2.31 as the base version of glibc. If I upgrade to 2.34, will that solve the other two errors that I'm receiving? I'd really like to run this as a linux server (or better, a container, but I saw your comment on Reddit with that).
Let me know what I can provide for you and I'd love to help.