Setup: Error Line 42 in commander script

[anselor]

Trying to do the docker install pulling the latest image right now.

labca-gui-1       | 2024/09/14 04:21:17 GET /restart?token=6d47721407bf4b7c
labca-gui-1       | 2024/09/14 04:21:17 ERROR: Message from server: 'ERROR! On line 42 in commander script
labca-gui-1       | '
labca-gui-1       | 2024/09/14 04:21:17 errorHandler: err=ERROR! On line 42 in commander script
labca-gui-1       | 
labca-gui-1       | main._hostCommand({0x13da458, 0xc000836380}, 0xc0008aa120, {0xe8d9ff, 0xe}, {0x0, 0x0, 0xe891cc?})
labca-gui-1       |     /go/src/labca/main.go:2278 +0x6a5
labca-gui-1       | main.restartHandler({0x13da458, 0xc000836380}, 0xc0008aa120)
labca-gui-1       |     /go/src/labca/main.go:2792 +0x2f7
labca-gui-1       | net/http.HandlerFunc.ServeHTTP(0xd61aa0?, {0x13da458?, 0xc000836380?}, 0xc000836380?)
labca-gui-1       |     /usr/local/go/src/net/http/server.go:2171 +0x29
labca-gui-1       | main.authorized.func1({0x13da458, 0xc000836380}, 0xc0008aa120)
labca-gui-1       |     /go/src/labca/main.go:3299 +0x337
labca-gui-1       | net/http.HandlerFunc.ServeHTTP(0xc0008aa000?, {0x13da458?, 0xc000836380?}, 0x4ffeef?)
labca-gui-1       |     /usr/local/go/src/net/http/server.go:2171 +0x29
labca-gui-1       | github.com/gorilla/mux.(*Router).ServeHTTP(0xc000000480, {0x13da458, 0xc000836380}, 0xc00089fe60)
labca-gui-1       |     /root/go/pkg/mod/github.com/gorilla/mux@v1.8.0/mux.go:210 +0x1e2
labca-gui-1       | net/http.serverHandler.ServeHTTP({0xc0008a4f90?}, {0x13da458?, 0xc000836380?}, 0x6?)
labca-gui-1       |     /usr/local/go/src/net/http/server.go:3142 +0x8e
labca-gui-1       | net/http.(*conn).serve(0xc0008167e0, {0x13dd0d8, 0xc0006ce060})
labca-gui-1       |     /usr/local/go/src/net/http/server.go:2044 +0x5e8
labca-gui-1       | created by net/http.(*Server).Serve in goroutine 1
labca-gui-1       |     /usr/local/go/src/net/http/server.go:3290 +0x4b4

[dhardyuk]

I'm guessing that this issue is why my fresh install is stalled with a spinning wheel on:

Restart
Almost there!
Now we will request a certificate for this website and restart one more time...

and filling the ACME log with this:

boulder-1  | 2024-09-14T08:16:03.492998+00:00Z boulder-ra[813]: 6 boulder-ra uoyS-AQ loading hostname policy, sha256: 61078421ae55b248741cdf62298943a5e9333da5f95209fceaece58613de9a8c
boulder-1  | 2024-09-14T08:16:03.500220+00:00Z boulder-ra[813]: 6 boulder-ra 3aT09Qk grpc listening on :9494
boulder-1  | health checking ra.boulder (localhost:9494)
boulder-1  | 2024-09-14T08:16:04.532257+00:00Z ocsp-responder[826]: 6 ocsp-responder p8br7QI Debug server listening on :8005
boulder-1  | 2024-09-14T08:16:04.532449+00:00Z ocsp-responder[826]: 6 ocsp-responder 5Jyw0gk Versions: ocsp-responder=(Unspecified Unspecified) Golang=(go1.22.5) BuildHost=(Unspecified)
boulder-1  | 2024-09-14T08:16:04.551097+00:00Z ocsp-responder[826]: 6 ocsp-responder gduRtgc HTTP server listening on :4002
boulder-1  | 2024-09-14T08:16:04.771303+00:00Z sfe[838]: 6 sfe 5qSHpQM Debug server listening on :8015
boulder-1  | 2024-09-14T08:16:04.771328+00:00Z sfe[838]: 6 sfe vs3M_gI Versions: sfe=(Unspecified Unspecified) Golang=(go1.22.5) BuildHost=(Unspecified)
boulder-1  | 2024-09-14T08:16:04.776191+00:00Z sfe[838]: 6 sfe j9vUnQs Server running, listening on :4003....
boulder-1  | 2024-09-14T08:18:03.375370+00:00Z crl-updater[806]: 3 crl-updater vNbG8gQ [AUDIT] Generating CRL failed: id=[{"issuerID":59506469441232435,"shardIdx":1,"crlNumber":1726301883351161407}] err=[computing shardmap: rpc error: code = Unknown desc = certificateStatus table notAfter column is empty]
boulder-1  | 2024-09-14T08:22:05.511145+00:00Z akamai-purger[738]: 6 akamai-purger 2f7Ciwo Shutting down; queue is already empty.
boulder-1  |  * Starting enhanced syslogd rsyslogd
boulder-1  |    ...done.
boulder-1  | Sat Sep 14 08:45:13 UTC 2024 - still trying to connect to boulder-mysql:3306
boulder-1  | Connected to boulder-mysql:3306
boulder-1  | Sat Sep 14 08:45:18 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:45:23 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:45:28 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:45:33 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:45:38 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:45:43 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:45:48 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:45:53 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:45:58 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:03 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:08 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:13 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:18 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:23 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:28 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:33 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:38 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:43 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:48 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:53 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:46:58 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:03 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:08 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:13 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:18 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:23 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:28 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:33 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:38 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:43 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:48 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:53 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:47:58 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:03 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:08 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:13 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:18 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:23 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:28 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:33 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | unable to connect
[Kboulder-1 exited with code 1
boulder-1  |  * Starting enhanced syslogd rsyslogd
boulder-1  |    ...done.
boulder-1  | Connected to boulder-mysql:3306
boulder-1  | Sat Sep 14 08:48:40 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:45 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:50 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:48:55 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:49:00 UTC 2024 - still trying to connect to bpkilint:80
boulder-1  | Sat Sep 14 08:49:05 UTC 2024 - still trying to connect to bpkilint:80

edited to reformat the log extract

[anselor]

@dhardyuk
Yeah, spinning on restart is what I was seeing too. I dug that error out of the docker logs.

[EsherionM]

I have the same problem and when i run "cd /home/labca/boulder; docker ps -a" i get this.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8f449c72e3cd letsencrypt/boulder-tools:go1.22.5_2024-08-13 "labca/entrypoint.sh" 23 minutes ago Up 27 seconds 0.0.0.0:4001-4003->4001-4003/tcp, :::4001-4003->4001-4003/tcp labca-boulder-1 8fc714158537 letsencrypt/boulder-tools:go1.22.5_2024-08-13 "./setup.sh" 23 minutes ago Up 44 seconds 3000/tcp labca-gui-1 d94a11a2632d nginx:1.26.0 "/docker-entrypoint.…" 23 minutes ago Up 26 seconds 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp labca-nginx-1 779176fb05c8 mariadb:10.5 "docker-entrypoint.s…" 23 minutes ago Up 54 seconds 3306/tcp labca-bmysql-1 48c68dcb48ec hashicorp/consul:1.15.4 "docker-entrypoint.s…" 23 minutes ago Up 55 seconds 8300-8302/tcp, 8500/tcp, 8301-8302/udp, 8600/tcp, 8600/udp labca-bconsul-1 376c55a0552e ghcr.io/digicert/pkilint:v0.10.1 "python entrypoint.p…" 23 minutes ago Up 55 seconds labca-bpkilint-1 3090bec946f8 letsencrypt/boulder-tools:go1.22.5_2024-08-13 "./control.sh" 23 minutes ago Up 23 minutes 3030/tcp labca-control-1
Is it normal, that labca-bpkilint-1 has no ports?

Maybe the log-entry ".... still trying to connect to bpkilint:80" has to do with it?

[dhardyuk]

So, I’m using the full install on Debian 12, which also pulls in the docker images.

After several complete redoes yesterday I realised that the setup completion was stalling and then my reboots were resulting in the “ still trying to connect to bpkilint:80” events after the reboot.

So a little rethink later and I focused on the CAA record in DNS. Which is a pain to configure on a Windows DNS server and I couldn’t work out how to do it on my MikroTik router.

Windows server doesn’t support the CAA record type so you need to use powershell to add in an ‘unknown type’ which you can find by googling - lots of examples from SSL cert slingers on how to add a CAA record this way.

I took a payload from somewhere and converted it from Hex to ASCII in notepad++ and then wrote my payload to match but with my lab domain name and then encoded that as hex and successfully added that to my Windows 2019 DNS server.

https://www.entrust.com/knowledgebase/ssl/how-to-add-a-certification-authority-authorization-record-caa-in-windows-server-2016

One more rebuild of everything later and setup completed successfully :-D

Same thing might work for you guys.
I might get someone from freelancer.com to make a form that takes all the values and spits out the powershell string as automating that conversion somehow would probably save a lot of people a lot of time.

My current problem is getting Synology DSM to request a cert via acme so I’m not out of the woods yet.

[anselor]

Trying to get my Synology box to request the cert is my real goal yesterday. I wasn't able to get it to work with step-ca so I thought I'd try with labca. I also tried installing labca in a Debian 12 LXC instead of doing the docker install.
I managed to get get past the issue with the CAA record but it then would fail because it couldn't resolve the .lan TLD.

@dhardyuk If you manage to get your Synology box to request a cert I would really appreciate if you could share the answer. I'm using opnsense and if has the ability to request a cert and publish it to the Synology box but I can't get it past any of the validation mechanisms. I ended up installing bind but couldn't figure out how to get the ducks in a row to let nsclient add the temporary txt record. I tried running acme.sh on the Synology box itself but can't figure out the parameters to even manually request the cert.

[anselor]

@dhardyuk ok, I know this isn't the right forum but I don't know how else to share this with you. I finally managed to get my Synology box to get a cert.

I followed the instructions here:
https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide

Installing acme.sh in the location they suggest.

I installed Synology Web Station but after everything I suspect that wasn't needed. You can try without doing that step.

The key thing that was quite confusing is the nginx configuration that drives all of the synology web interface has a global override for the sub-path that acme HTTP-01 validation tries to search for.

You need to manually create this directory: /var/lib/letsencrypt

All requests to the acme HTTP-01 validation URL end up there.

I ran this to get the initial cert:

acme.sh --issue -d internal.lan --server https://ca.internal.lan/acme/acme/directory --ca-bundle /var/db/ca-certificates/ca.internal.lan.crt --days '1' --force -w /var/lib/letsencrypt --standalone

Then followed the instructions to deploy using a temporary admin user.

NOTE: This worked using a step-ca server. I could never get labca to finish its initial configuration.

[dhardyuk]

@anselor - I couldn't get this to work for me with labca 😶.

I've gone nuclear in the other direction and registered a pp.ua domain (for free) and then migrated my entire lab to use the new internet valid domain. Currently have my Synology using a letsencrypt cert and will revisit in a couple of months.

Thanks for your help 👍