AdGuard Home Wildcard aliases
-
@girish said in AdGuard Home Wildcard aliases:
Yeah, so they never got back I even sent them a reminder. Please point them to this thread (if you are a customer). I sent mails from girish@cloudron.io
you got maybe any ticket number? I will contact them now
-
@girish update to latest Cloudron Version, bunny.net integration is working fine (thanks for this), but DoT on my Android Phone is still not working, in AdGuard Home Log I see:
May 02 10:35:57 2023/05/02 08:35:57.599729 [error] handling tcp: reading msg: reading len: remote error: tls: bad certificate May 02 10:35:57 2023/05/02 08:35:57.907614 [error] handling tcp: reading msg: reading len: remote error: tls: bad certificate May 02 10:35:57 2023/05/02 08:35:57.914408 [error] handling tcp: reading msg: reading len: remote error: tls: bad certificate
What is wrong? I use <clientname>.adguard.mydomain.TLD and I added an Alias (*.adgaurd) to AdGuard Home.
What is wrong?
Thank you and Regards,
Lukas -
@girish update to latest Cloudron Version, bunny.net integration is working fine (thanks for this), but DoT on my Android Phone is still not working, in AdGuard Home Log I see:
May 02 10:35:57 2023/05/02 08:35:57.599729 [error] handling tcp: reading msg: reading len: remote error: tls: bad certificate May 02 10:35:57 2023/05/02 08:35:57.907614 [error] handling tcp: reading msg: reading len: remote error: tls: bad certificate May 02 10:35:57 2023/05/02 08:35:57.914408 [error] handling tcp: reading msg: reading len: remote error: tls: bad certificate
What is wrong? I use <clientname>.adguard.mydomain.TLD and I added an Alias (*.adgaurd) to AdGuard Home.
What is wrong?
Thank you and Regards,
Lukas -
@lukas If you go to Location view and click Save (without making any changes), does that help the situation ? That should maybe (re)trigger getting the cert.
-
@lukas can you check the output of
openssl x509 -text -in /etc/certs/_.adguard.domain.cert
in the web terminal of adguard ? Does it seem like a valid Let's Encrypt certificate? -
@lukas The first few lines should give us the issuer and expiry like this:
Certificate: Data: Version: 3 (0x2) Serial Number: 04:1d:71:e7:48:c7:d3:80:02:ac:c1:ac:5b:79:e5:3f:3e:4e Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = R3 Validity Not Before: Apr 15 02:11:00 2023 GMT Not After : Jul 14 02:10:59 2023 GMT
Then later down, you should also see the SAN section:
X509v3 Subject Alternative Name: DNS:*.girish.in
Ideally, there should the wildcard and non-wildcard DNS listed above in your case.
-
@lukas The first few lines should give us the issuer and expiry like this:
Certificate: Data: Version: 3 (0x2) Serial Number: 04:1d:71:e7:48:c7:d3:80:02:ac:c1:ac:5b:79:e5:3f:3e:4e Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = R3 Validity Not Before: Apr 15 02:11:00 2023 GMT Not After : Jul 14 02:10:59 2023 GMT
Then later down, you should also see the SAN section:
X509v3 Subject Alternative Name: DNS:*.girish.in
Ideally, there should the wildcard and non-wildcard DNS listed above in your case.
Certificate: Data: Version: 3 (0x2) Serial Number: 36:5d:97:51:3d:9f:45:89:58:45:67:c2:82:a6:83:3f:6d:50:69:0b Signature Algorithm: sha256WithRSAEncryption Issuer: CN = *.mydomain.cloud Validity Not Before: Apr 2 14:06:15 2023 GMT Not After : Jun 10 14:06:15 2025 GMT
and
X509v3 extensions: X509v3 Subject Alternative Name: DNS:mydomain.cloud, DNS:*.mydomain.cloud
-
Certificate: Data: Version: 3 (0x2) Serial Number: 36:5d:97:51:3d:9f:45:89:58:45:67:c2:82:a6:83:3f:6d:50:69:0b Signature Algorithm: sha256WithRSAEncryption Issuer: CN = *.mydomain.cloud Validity Not Before: Apr 2 14:06:15 2023 GMT Not After : Jun 10 14:06:15 2025 GMT
and
X509v3 extensions: X509v3 Subject Alternative Name: DNS:mydomain.cloud, DNS:*.mydomain.cloud
-
@lukas It's not getting the new certs for some reason - it's using the self-signed cert. If you go to Domains -> Renew all certs. Can you check the logs when it's renewing? Do you see any errors?
-
@lukas From the logs, it seems the domain is not using Wildcard certs at all. If you go to Domains -> Edit -> Advanced. What is the certificate provider ? I suspect it's not wildcard . Can you change it and try to renew certs again?
I guess the reason is because you went from maybe Wildcard DNS to Programmatic DNS. In wildcard DNS, wildcard cert is not possible. But this is indeed a workflow/ui thing, that we have to consider in the future.
-
@lukas From the logs, it seems the domain is not using Wildcard certs at all. If you go to Domains -> Edit -> Advanced. What is the certificate provider ? I suspect it's not wildcard . Can you change it and try to renew certs again?
I guess the reason is because you went from maybe Wildcard DNS to Programmatic DNS. In wildcard DNS, wildcard cert is not possible. But this is indeed a workflow/ui thing, that we have to consider in the future.
-
@girish so which steps do I need to go, to get this resolved?
Btw. I see there some "non-used" SSL certificates, is there any kind of "housekeeping" ?
-
@lukas I am a bit lost at this point. Are you able contact me at support@cloudron.io , so I can debug your instance?
-
@girish said in AdGuard Home Wildcard aliases:
@lukas thanks! As a heads up, I will only be able to debug a bit later today.
all right, thank you very much for your amazing support!
@lukas Thanks for the access. I found the root cause. I (re)learnt about Let's Encrypts validation cache.
<tech stuff>
It's a very corner case but, unfortunately, it's hit in your situation.
- You used to have wildcard DNS before. This results in Let's Encrypt HTTP validation (http-01)
- You switched to Bunny DNS. The code now expects to do Let's Encrypt DNS validation (dns-01)
- Turns out , Let's Encrypt will "remember" authorization for 60 days (in some places, it says 30 days). So, it will continue to ask for HTTP validation . The code gets confused because is really wants DNS validation.
If you want to read more:
- https://community.letsencrypt.org/t/flush-of-authorization-cache/188043
- https://community.letsencrypt.org/t/let-s-encrypt-s-vulnerability-as-a-feature-authz-reuse-and-eternal-account-key/21687
- https://community.letsencrypt.org/t/http-01-validation-cache/22529
</tech stuff>
I fixed our code to handle this - https://git.cloudron.io/cloudron/box/-/commit/15e0f11bb9815f5e4e7637cf29cf4fd17ccd2da2 . I applied the fix on your server and it seems to work. Atleast, the certs are correct now and we can now go back to checking if AdGuard is working for you. Can you check?
-
@lukas Thanks for the access. I found the root cause. I (re)learnt about Let's Encrypts validation cache.
<tech stuff>
It's a very corner case but, unfortunately, it's hit in your situation.
- You used to have wildcard DNS before. This results in Let's Encrypt HTTP validation (http-01)
- You switched to Bunny DNS. The code now expects to do Let's Encrypt DNS validation (dns-01)
- Turns out , Let's Encrypt will "remember" authorization for 60 days (in some places, it says 30 days). So, it will continue to ask for HTTP validation . The code gets confused because is really wants DNS validation.
If you want to read more:
- https://community.letsencrypt.org/t/flush-of-authorization-cache/188043
- https://community.letsencrypt.org/t/let-s-encrypt-s-vulnerability-as-a-feature-authz-reuse-and-eternal-account-key/21687
- https://community.letsencrypt.org/t/http-01-validation-cache/22529
</tech stuff>
I fixed our code to handle this - https://git.cloudron.io/cloudron/box/-/commit/15e0f11bb9815f5e4e7637cf29cf4fd17ccd2da2 . I applied the fix on your server and it seems to work. Atleast, the certs are correct now and we can now go back to checking if AdGuard is working for you. Can you check?
-
G girish has marked this topic as solved on