Fatal error on startup with wildcard certificates #235

tionis commented 2023年07月20日 16:06:59 +02:00

I'm currently trying to deploy pages in a docker container built using the Dockerfile in the repo and using cloudflare for wildcard cert generation. On startup I'm getting the following error:

pages | 2:00PM ERR toCert conversion did discover mismatch error="domain key '*.tasadar.page' and cert domain 'tasadar.page' not equal"
pages | 2:00PM ERR Couldn't get cert for domain ".tasadar.page"

which seems to be related to following database interface code:

I'm currently trying to deploy pages in a docker container built using the Dockerfile in the repo and using cloudflare for wildcard cert generation. On startup I'm getting the following error: ``` pages | 2:00PM ERR toCert conversion did discover mismatch error="domain key '*.tasadar.page' and cert domain 'tasadar.page' not equal" pages | 2:00PM ERR Couldn't get cert for domain ".tasadar.page" ``` which seems to be related to following database interface code: https://codeberg.org/Codeberg/pages-server/src/commit/d720d25e42eb5f1e63462a6665afdd0bebd364ae/server/database/interface.go#L63

thystips commented 2023年07月30日 23:55:48 +02:00

Same problem for me :

[INFO] [pages.git.antoinethys.net] Server responded with a certificate.
ERR toCert conversion did discover mismatch error="domain key '*.pages.git.antoinethys.net' and cert domain 'pages.git.antoinethys.net' not equal"
ERR Couldn't get cert for domain ".pages.git.antoinethys.net"
http: TLS handshake error from 172.23.0.1:47138: won't request certificate for main domain, something really bad has happened

Same problem for me : ``` [INFO] [pages.git.antoinethys.net] Server responded with a certificate. ERR toCert conversion did discover mismatch error="domain key '*.pages.git.antoinethys.net' and cert domain 'pages.git.antoinethys.net' not equal" ERR Couldn't get cert for domain ".pages.git.antoinethys.net" http: TLS handshake error from 172.23.0.1:47138: won't request certificate for main domain, something really bad has happened ```

thepaperpilot commented 2023年09月17日 15:58:17 +02:00

I also ran into this issue, and found checking out the commit from the most recent release (v4.6.3) resolved it for me. I'm a bit confused since that was released 3 weeks ago and the two comments above me are older than that, but it's possible this issue was fixed but then re-introduced.

I also ran into this issue, and found checking out the commit from the most recent release (v4.6.3) resolved it for me. I'm a bit confused since that was released 3 weeks ago and the two comments above me are older than that, but it's possible this issue was fixed but then re-introduced.

crapStone commented 2023年11月15日 21:27:03 +01:00

Is this fixed by using the latest version?

Is this fixed by using the latest version?

drhirn commented 2023年11月20日 12:46:26 +01:00

Unfortunately not

Unfortunately not

histausse commented 2024年02月15日 23:28:02 +01:00

I ran into the same issue with OVH as my domain provider and the v5.1 release of pages-server

I ran into the same issue with OVH as my domain provider and the v5.1 release of pages-server

histausse commented 2024年02月24日 21:11:08 +01:00

After some investigation, I believe the problem comes from

:

When requesting the main certificate, wildcard domain is explicitly removed from the requested domains, leading to the request of a non-wildcard certificate:

$ sqlite3 certs.sqlite "SELECT certificate FROM cert WHERE domain = 'page.example.com' OR domain = '*.page.example.com" | openssl x509 -noout -ext subjectAltName -subject
X509v3 Subject Alternative Name:
 DNS:page.example.com
subject=CN = page.example.com

When removing the 3 lines from the code, the certificate requested now match the one used in prod by codeberg.page:

$ sqlite3 certs.sqlite "SELECT certificate FROM cert WHERE domain = 'page.example.com' OR domain = '*.page.example.com'" | openssl x509 -noout -ext subjectAltName -subject
X509v3 Subject Alternative Name:
 DNS:*.page.example.com, DNS:page.example.com
subject=CN = *.page.example.com
$ echo | openssl s_client -connect codeberg.page:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -ext subjectAltName -subject
Warning: Reading certificate from stdin since no -in or -new option is given
X509v3 Subject Alternative Name:
 DNS:*.codeberg.page, DNS:codeberg.page
subject=CN=*.codeberg.page

Because of

, an instance with an already valid cert will keep renewing the valid cert and not run into this issue, but a new instance is not able to generate a new certificate.

After some investigation, I believe the problem comes from https://codeberg.org/Codeberg/pages-server/src/commit/7e80ade24b8aac072804122b343a2a1a70667983/server/certificates/certificates.go#L202-L204: When requesting the main certificate, wildcard domain is explicitly removed from the requested domains, leading to the request of a non-wildcard certificate: ``` $ sqlite3 certs.sqlite "SELECT certificate FROM cert WHERE domain = 'page.example.com' OR domain = '*.page.example.com" | openssl x509 -noout -ext subjectAltName -subject X509v3 Subject Alternative Name: DNS:page.example.com subject=CN = page.example.com ``` When removing the 3 lines from the code, the certificate requested now match the one used in prod by codeberg.page: ``` $ sqlite3 certs.sqlite "SELECT certificate FROM cert WHERE domain = 'page.example.com' OR domain = '*.page.example.com'" | openssl x509 -noout -ext subjectAltName -subject X509v3 Subject Alternative Name: DNS:*.page.example.com, DNS:page.example.com subject=CN = *.page.example.com $ echo | openssl s_client -connect codeberg.page:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -ext subjectAltName -subject Warning: Reading certificate from stdin since no -in or -new option is given X509v3 Subject Alternative Name: DNS:*.codeberg.page, DNS:codeberg.page subject=CN=*.codeberg.page ``` Because of https://codeberg.org/Codeberg/pages-server/src/commit/7e80ade24b8aac072804122b343a2a1a70667983/server/certificates/certificates.go#L228-L233, an instance with an already valid cert will keep renewing the valid cert and not run into this issue, but a new instance is not able to generate a new certificate.