Could not look up a certificate for server name 'domain'

[newdev8]

I just installed sozu and setup my config as follows:

[[listeners]]
address = "0.0.0.0:443"
protocol = "https"
tls_versions = ["TLSv1.2", "TLSv1.3"]
cipher_list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"

[applications]

[applications.AppName]
protocol = "http"
https_redirect = true

frontends = [
  { address = "127.0.0.1:1444", hostname = "domain", certificate = "/etc/domain/cert.pem", key = "/etc/domain/key.pem", certificate_chain = "/etc/cloudflare/chain.pem" }
]

backends  = [
  { address = "127.0.0.1:444" }
]

But when I access my domain from the browser I get the following error:

could not look up a certificate for server name 'domain'
Sending fatal alert AccessDenied
could not perform handshake: General("no server certificate chain resolved")

[FlorentinDUBOIS]

Hello,

We have made some improvements to the certificate part on the branch 0.14. Could you test using this version ?

I will try to reproduce your issue on the main branch as well.

[newdev8]

Hey, after trying branch 0.14 I am still getting the same error.
Maybe it's me doing something wrong.
I am running an actix server on port 444 with the same SSL certificate/key as the one used in my sozu configuration file.

[FlorentinDUBOIS]

Thank you! Sounds interesting, I will take a look at it.

[PlainBane]

Hello,
The issue is lib/src/router/trie.rs ~162
pub fn lookup(&self, partial_key: &[u8], accept_wildcard: bool)
The domain lookup by key fails sometimes. It doesn't seem to handle subdomains correctly. It depends on what it has on domains list and what key it is looking for. I can't test it with domain wildcards, so can't fix it. I made a quick and dirty work-around in my code an it works fine.

[ToBinio]

Hello,
just wanted to ask if there is any progress on this issue?

and btw thanks for the excellent work on this project

[justinkb]

still happening on 0.15.3 - makes the program unusable. no rhyme or reason to it either, seems to happen randomly to different clusters upon restarting the daemon

[justinkb]

so, the issue is in the CertificateResolver in tls.rs. If I have a wildcard certificate for *.domain.tld, and I have say, three defined clusters with an domain.tld subdomain frontend each, for example, a.domain.tld, b.domain.tld and c.domain.tld, add_certificate will not end up associating two of the three domain names with that certificate (randomly at startup, based on whichever thread ends up calling the function first) because the add_certificate function bails out once it finds the already present fingerprint of the wildcard certificate...

        // We do not need to update the entry, if the certificate is already registered
        if self.get_certificate(&fingerprint).is_some() {
            return Ok(fingerprint);
        }

This makes domain_lookup fail for those frontends. I have no clue how this design issue has gone unnoticed so far, seems like some test should have caught it

[justinkb]

removing that code snippet above fixes the issue and doesn't break any test. seems like it was just faulty logic that has been present since that bit of code was rewritten in a7952a1

[Keksoj]

Hello to you all and thanks for the precise reporting.
As of today's 0.15.3 version of Sōzu, removing this code doesn't seem to affect the tests. I pushed a branch and opened this pull request: #988

However, the best thing would be to add an e2e test. What do you think @Wonshtrum ?

[justinkb]

I will note that I've observed that querying sozu for information about certificates via the cli fails to list all domains associated (through clusters) with a cert fingerprint. Instead it seems to just list one, not sure if randomly or just the first one or last one (not that it matters)

…

On Mon, Sep 11, 2023, 5:43 PM Emmanuel Bosquet ***@***.***> wrote: Hello to you all and thanks for the precise reporting. As of today's 0.15.3 version of Sōzu, removing this code doesn't seem to affect the tests. I pushed a branch and opened this pull request: #988 <#988> However, the best thing would be to add an e2e test. What do you think @Wonshtrum <https://github.com/Wonshtrum> ? — Reply to this email directly, view it on GitHub <#774 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABVHKBN5TZTAHKXJNCEWFTXZ4WQJANCNFSM53OEEC6A> . You are receiving this because you commented.Message ID: ***@***.***>

[Keksoj]

We merged the #988 pull request that removes this code snippet. It would be great for you people to test that Sōzu's behaviour works for you with subdomain certificates.

About the CLI behaviour, it would be awesome if you created a new issue with the issued commands and related bugs. I am responsible for the CLI rework.