Error during installation about labca

[hakwerk]

Debian 11 should be fine, I just haven't come around to testing it myself yet.

If you simply run the local /home/labca/labca/install script now, it should work and correct itself.

Your issue was caused by a small bug as there are commits on the main branch after the latest release. This should be fixed now, so it should also work when starting completely from scratch again.

[hakwerk]

I won't have time to look further into special chars until next week, so you'll probably want to use a different organization name for now.

I'm glad we at least know now what the root cause was!

[SachsKaylee]

Thank you, I deleted and recreated the VM and ran the updated script - the CA installed just fine.

When setting up I got the following error after confirming my root CA and intermediate:

OOPS

Some unexpected error occurred!

Diagnostics

These log files might help you determine what the problem is:

docker-compose logs labca

Attaching to boulder_labca_1
labca_1    | Reading package lists...
labca_1    | Building dependency tree...
labca_1    | Reading state information...
labca_1    | The following NEW packages will be installed:
labca_1    |   zip
labca_1    | 0 upgraded, 1 newly installed, 0 to remove and 38 not upgraded.
labca_1    | Need to get 167 kB of archives.
labca_1    | After this operation, 638 kB of additional disk space will be used.
labca_1    | Get:1 http://archive.ubuntu.com/ubuntu focal/main amd64 zip amd64 3.0-11build1 [167 kB]
labca_1    | debconf: delaying package configuration, since apt-utils is not installed
labca_1    | Fetched 167 kB in 1s (334 kB/s)
labca_1    | Selecting previously unselected package zip.
labca_1    | (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 19773 files and directories currently installed.)
labca_1    | Preparing to unpack .../zip_3.0-11build1_amd64.deb ...
labca_1    | Unpacking zip (3.0-11build1) ...
labca_1    | Setting up zip (3.0-11build1) ...
labca_1    | 
labca_1    | bin/labca
labca_1    | 2022/04/06 13:22:17 Listening on 0.0.0.0:3000...
labca_1    | 2022/04/06 13:22:38 GET /
labca_1    | 2022/04/06 13:22:46 GET /login
labca_1    | 2022/04/06 13:22:52 GET /setup
labca_1    | 2022/04/06 13:35:47 GET /
labca_1    | 2022/04/06 13:35:47 GET /login
labca_1    | 2022/04/06 13:35:47 GET /setup
labca_1    | 2022/04/06 13:36:16 GET /setup
labca_1    | 2022/04/06 13:36:17 GET /setup
labca_1    | 2022/04/06 13:37:30 POST /setup
labca_1    | 2022/04/06 13:39:06 POST /setup
labca_1    | 2022/04/06 13:39:38 POST /setup
labca_1    | 2022/04/06 13:39:52 POST /setup
labca_1    | exit status 1: sed: -e expression #1, char 102: invalid reference \8 on `s' command's RHS
labca_1    | 
labca_1    | 2022/04/06 13:39:54 errorHandler: err=exit status 1
labca_1    | main.setupHandler({0x9c15a8, 0xc0006161c0}, 0xc00053ee00)
labca_1    | 	/go/src/labca/main.go:1823 +0x532
labca_1    | net/http.HandlerFunc.ServeHTTP(0x897440, {0x9c15a8, 0xc0006161c0}, 0x5)
labca_1    | 	/usr/local/go/src/net/http/server.go:2047 +0x2f
labca_1    | main.authorized.func1({0x9c15a8, 0xc0006161c0}, 0xc00053ee00)
labca_1    | 	/go/src/labca/main.go:2372 +0x21a
labca_1    | net/http.HandlerFunc.ServeHTTP(0xc00053ed00, {0x9c15a8, 0xc0006161c0}, 0xd1a080)
labca_1    | 	/usr/local/go/src/net/http/server.go:2047 +0x2f
labca_1    | github.com/gorilla/mux.(*Router).ServeHTTP(0xc00028e240, {0x9c15a8, 0xc0006161c0}, 0xc00053eb00)
labca_1    | 	/go/pkg/mod/github.com/gorilla/[email protected]/mux.go:210 +0x1cf
labca_1    | net/http.serverHandler.ServeHTTP({0x9c0620}, {0x9c15a8, 0xc0006161c0}, 0xc00053eb00)
labca_1    | 	/usr/local/go/src/net/http/server.go:2879 +0x43b
labca_1    | net/http.(*conn).serve(0xc00061e6e0, {0x9c4440, 0xc00060b860})
labca_1    | 	/usr/local/go/src/net/http/server.go:1930 +0xb08
labca_1    | created by net/http.(*Server).Serve
labca_1    | 	/usr/local/go/src/net/http/server.go:3034 +0x4e8
ok

docker-compose logs boulder

Attaching to boulder_boulder_1
boulder_1  | added users to boulder_sa_test
boulder_1  | 
boulder_1  | �[0;34;1mChecking if boulder_sa_integration exists�[0m
boulder_1  | boulder_sa_integration doesn't exist - creating
boulder_1  | created empty boulder_sa_integration database
boulder_1  | applying migrations from ./sa/_db/migrations
boulder_1  | goose: migrating db environment 'integration', current version: 0, target: 20210924100000
boulder_1  | OK    20210223140000_CombinedSchema.sql
boulder_1  | OK    20210308140000_SimplePartitioning.sql
boulder_1  | OK    20210924100000_OldFQDNSets.sql
boulder_1  | added users to boulder_sa_integration
boulder_1  | 
boulder_1  | database setup complete
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
boulder_1  | Waiting for /boulder/labca/setup_complete to appear...
ok

[hakwerk]

labca_1    | exit status 1: sed: -e expression #1, char 102: invalid reference \8 on `s' command's RHS

Hmm never seen that before. No idea where that \8 reference could be coming from.

Are there any empty files in /home/labca/boulder_labca/ or /home/labca/boulder_labca/config (apart from setup_complete), or remaining .bak files?

[SachsKaylee]

Thanks for the quick reply! A quick glimpse did not show any empty or bak files. I also don't have a setup_complete file/directory as far as I can tell. I've attached screenshots of the two directories in case I missed something or you can spot something that might help:

[hakwerk]

Sorry, right, the setup_complete file does not exist yet because of the error message. Looking at the timestamps all being the same for these files, it looks like the apply-boulder script did not even start modifying the config files, so the issue must be coming from the apply-nginx script.

Could you try the following:

docker exec -it boulder_labca_1 /bin/bash

And then from inside the docker container run these commands:

# export PKI_ROOT_CERT_BASE=/go/src/labca/data/root-ca
# export PKI_INT_CERT_BASE=/go/src/labca/data/issuer/ca-int
# cd /wwwstatic/
# /go/src/labca/apply-nginx

Hopefully that gives some clue on why it fails. Maybe it can't extract the info from the root and intermediate certificates. If there is still no useful error message here, try these commands manually from that same docker session:

# openssl x509 -noout -in $PKI_ROOT_CERT_BASE.pem -subject | sed -e "s/subject= //"
# openssl x509 -noout -in $PKI_ROOT_CERT_BASE.pem -startdate | sed -e "s/.*=/Not Before: /"
# openssl x509 -noout -in $PKI_ROOT_CERT_BASE.pem -enddate | sed -e "s/.*=/Not After: /"
# openssl x509 -noout -in $PKI_INT_CERT_BASE.pem -subject | sed -e "s/subject= //"
# openssl x509 -noout -in $PKI_INT_CERT_BASE.pem -startdate | sed -e "s/.*=/Not Before: /"
# openssl x509 -noout -in $PKI_INT_CERT_BASE.pem -enddate | sed -e "s/.*=/Not After: /"
# openssl x509 -noout -in $PKI_ROOT_CERT_BASE.pem -fingerprint | sed -e "s/.*=//" | sed -e "s/.\{21\}/&\\\n/g"

Finally if this all still is fine, there could be something wrong with the Organization name, please check if this command inside the docker container looks suspicious:

# grep organization /go/src/labca/data/config.json

It should be two simple strings, something like

    "organization": "Test Inc."

[SachsKaylee]

Going to check the commands above now, but when reading your reply I got a sneaking suspicion:

Finally if this all still is fine, there could be something wrong with the Organization name, please check if this command inside the docker container looks suspicious:

The organization name I entered is "Sahnee UG (haftungsbeschränkt)" (note the "ä" umlaut). Are special characters supported in organization names?
In any case, Ill try the commands above and report the result.

[SachsKaylee]

Jup, definitely looks like the organization name. Should I just use a different one or do you think this is an easy/quick fix if its possible at all?

[SachsKaylee]

Sounds good, thank you for your time!

[hakwerk]

The latest release now can handle special characters in the organization name, and they also show up properly in the certificates.
As often is the case, the fix was rather simple once I determined the root of the problem 😄