Facing TLS error on Technitium DNS

[EliteSalman]

Hi,

I facing a mysterious issue on my Technitium DNS Server,

I used a tls certificate pfx file all working fine decoder.link showing on port 853 valid certificate and also from the kdig tool the DoT working perfectly but on Android it's showing invalid certificate I don't know why I using ZeroSSL then I checked the log and got this:-

[2026-06-08 16:04:25 UTC] DNS Server encountered an error while updating Web Service TLS Certificate: /etc/dns/tls/cert_new.pfx
System.Security.Cryptography.CryptographicException: The certificate data cannot be read with the provided password, the password may be incorrect.
at System.Security.Cryptography.X509Certificates.X509CertificateLoader.ThrowWithHResult(String message, Int32 hResult)
at System.Security.Cryptography.X509Certificates.X509CertificateLoader.ReadCertsAndKeys(BagState& bagState, ReadOnlyMemory1 data, ReadOnlySpan1& password, Pkcs12LoaderLimits loaderLimits)
at System.Security.Cryptography.X509Certificates.X509CertificateLoader.LoadPkcs12Collection(ReadOnlyMemory1 data, ReadOnlySpan1 password, X509KeyStorageFlags keyStorageFlags, Pkcs12LoaderLimits loaderLimits)
at System.Security.Cryptography.X509Certificates.X509CertificateLoader.LoadFromFile[T](String path, ReadOnlySpan1 password, X509KeyStorageFlags keyStorageFlags, Pkcs12LoaderLimits loaderLimits, LoadFromFileFunc1 loader)
at System.Security.Cryptography.X509Certificates.X509CertificateLoader.LoadPkcs12CollectionFromFile(String path, ReadOnlySpan`1 password, X509KeyStorageFlags keyStorageFlags, Pkcs12LoaderLimits loaderLimits)
at DnsServerCore.DnsWebService.LoadWebServiceTlsCertificate(String tlsCertificatePath, String tlsCertificatePassword) in Z:\Technitium\Projects\DnsServer\DnsServerCore\DnsWebService.cs:line 2554
at DnsServerCore.DnsWebService.b__80_0(Object state) in Z:\Technitium\Projects\DnsServer\DnsServerCore\DnsWebService.cs:line 2513
[2026-06-08 16:04:28 UTC] DNS Server log config file was saved: /etc/dns/log.config

Best Regards,
Salman Shafi

[ShreyasZare]

Thanks for the post. From the error log you shared, it looks like the new cert has failed to load probably due to issue with the pfx password. If you have set password to pfx file then make sure that the password is configured correctly in the DNS server. You can also download the pfx file and check if the cert file is correct.

The other thing you can do to test with cert issues is by running the openssl command. You can use the openssl s_client -connect example.com:443 command which will show you the details of the certs you have on the DoT service. That should give you some clues like if CA cert is missing in there.

[EliteSalman]

Thanks for the post. From the error log you shared, it looks like the new cert has failed to load probably due to issue with the pfx password. If you have set password to pfx file then make sure that the password is configured correctly in the DNS server. You can also download the pfx file and check if the cert file is correct.

The other thing you can do to test with cert issues is by running the openssl command. You can use the openssl s_client -connect example.com:443 command which will show you the details of the certs you have on the DoT service. That should give you some clues like if CA cert is missing in there.

The Cert loading error fixed but the TLS Trust issue on Android still not fixed after researching I found that Technitium only Provides TLS Certs Leaf Cert + 1 Intermediate CA to the client only even if more than one 1 Intermediate CA available or Root CA available on .pfx I confirmed this by with openssl,decoder.link,etc like tools also Same Cert working on AdGuard Home because AdGuard Home providing full chain to the client. You may ask how worked Previously on Technitium same issuer cert like Let's Encrypt or ZeroSSL because previously they only provides leaf cert > intermediate > root ca Technitium skiped providing root ca but the intermediate was issued by an cert that is already available in android store so root ca in chain providing not needed but now Let's Encrypt are using leaf cert (domain cert) > intermediate (YE1) > intermediate (ISRG Root YE) > Root CA (ISRG Root X2) even further more if used ISRG X2 crossed by X1. Plz fix this issue ASAP without fixing this many people will face issue like me and they will waste their time by debugging this.

[Hemsby]

I'm using Android phone, having a 3 node cluster with trusted self signed Ca and leaf certs for my servers at home and not seeing this. You need to provide more info and traces and not just say it's not working.

[EliteSalman]

I'm using Android phone, having a 3 node cluster with trusted self signed Ca and leaf certs for my servers at home and not seeing this. You need to provide more info and traces and not just say it's not working.

Which version of Android are you using, and what is the OS manufacturer? By the way, I am not talking about self-signed TLS — that is fine because it just has a leaf cert → intermediate, issued by a Trusted Root CA that is already on your phone. I am facing an issue after Let's Encrypt & ZeroSSL switched to their new intermediate + root CA chain. As I explained in my previous reply, I will explain it again here in detail:

Let's Encrypt previously gave just 3 parts in fullchain.pem:

1. Leaf Cert (dns.example.tld)
2. Intermediate Cert (E7/E8)
3. Root Cert (ISRG X1)

With this cert, even if Technitium did not provide the Root CA to the client, there was no issue — because E7/E8 was issued by ISRG X1, which is already present in the Android Trust Store.

Now in 2026, Let's Encrypt is giving:

1. Leaf Cert (dns.example.tld)
2. Intermediate (YE1/YE2)
3. Intermediate (ISRG Root YE)
4. Intermediate (ISRG Root X2)
5. Root CA (ISRG Root X1)

In this situation, Technitium only provides the client with certs 1 & 2 — i.e., the leaf cert + Intermediate YE1/YE2. Android sees that YE1/YE2 is issued by ISRG Root YE, which is not available in the Android Trust Store, so it is untrusted. Even if the Intermediate CA ISRG Root YE is also included in the chain, the same problem occurs — because you need to provide ISRG Root X2 in the chain as well. On your device it is showing as trusted because ISRG Root X2 is issued by ISRG Root X1, which is available in the Android Trust Store.

[EliteSalman]

I'm using Android phone, having a 3 node cluster with trusted self signed Ca and leaf certs for my servers at home and not seeing this. You need to provide more info and traces and not just say it's not working.

Which version of Android are you using, and what is the OS manufacturer? By the way, I am not talking about self-signed TLS — that is fine because it just has a leaf cert → intermediate, issued by a Trusted Root CA that is already on your phone. I am facing an issue after Let's Encrypt & ZeroSSL switched to their new intermediate + root CA chain. As I explained in my previous reply, I will explain it again here in detail:

Let's Encrypt previously gave just 3 parts in fullchain.pem:

1. Leaf Cert (dns.example.tld)
2. Intermediate Cert (E7/E8)
3. Root Cert (ISRG X1)

With this cert, even if Technitium did not provide the Root CA to the client, there was no issue — because E7/E8 was issued by ISRG X1, which is already present in the Android Trust Store.

Now in 2026, Let's Encrypt is giving:

1. Leaf Cert (dns.example.tld)
2. Intermediate (YE1/YE2)
3. Intermediate (ISRG Root YE)
4. Intermediate (ISRG Root X2)
5. Root CA (ISRG Root X1)

In this situation, Technitium only provides the client with certs 1 & 2 — i.e., the leaf cert + Intermediate YE1/YE2. Android sees that YE1/YE2 is issued by ISRG Root YE, which is not available in the Android Trust Store, so it is untrusted. Even if the Intermediate CA ISRG Root YE is also included in the chain, the same problem occurs — because you need to provide ISRG Root X2 in the chain as well. On your device it is showing as trusted because ISRG Root X2 is issued by ISRG Root X1, which is available in the Android Trust Store.

The RFC Standards thats breaked by Techntium:-

https://www.rfc-editor.org/info/rfc5246/#section-7.4.2

https://www.rfc-editor.org/info/rfc8446/#section-4.4.2

[arthur-2sheds-jackson]

Are you packing all of the necessary intermediate certs into the pfx file?

[ShreyasZare]

The Cert loading error fixed but the TLS Trust issue on Android still not fixed after researching I found that Technitium only Provides TLS Certs Leaf Cert + 1 Intermediate CA to the client only even if more than one 1 Intermediate CA available or Root CA available on .pfx I confirmed this by with openssl,decoder.link,etc like tools also Same Cert working on AdGuard Home because AdGuard Home providing full chain to the client. You may ask how worked Previously on Technitium same issuer cert like Let's Encrypt or ZeroSSL because previously they only provides leaf cert > intermediate > root ca Technitium skiped providing root ca but the intermediate was issued by an cert that is already available in android store so root ca in chain providing not needed but now Let's Encrypt are using leaf cert (domain cert) > intermediate (YE1) > intermediate (ISRG Root YE) > Root CA (ISRG Root X2) even further more if used ISRG X2 crossed by X1. Plz fix this issue ASAP without fixing this many people will face issue like me and they will waste their time by debugging this.

Yes, the DNS admin web service does not include root cert in the TLS handshake. The implementation uses Kestrel web server and all of the certificates available in the pfx file are provided to the web server. The Kestrel web server chooses what certs to use with the handshake and there is no option to control this aspect. So, there is pretty much nothing that can be done about it.

The RFC Standards thats breaked by Techntium:-

https://www.rfc-editor.org/info/rfc5246/#section-7.4.2

https://www.rfc-editor.org/info/rfc8446/#section-4.4.2

RFC 5246

This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.

RFC 8446

The sender's certificate MUST come in the first
CertificateEntry in the list. Each following certificate SHOULD
directly certify the one immediately preceding it. Because
certificate validation requires that trust anchors be distributed
independently, a certificate that specifies a trust anchor MAY be
omitted from the chain, provided that supported peers are known to
possess any omitted certificates.

Both these RFCs say pretty much the same thing that the root certs can be omitted from the chain.

Now in 2026, Let's Encrypt is giving:

1. Leaf Cert (dns.example.tld)
2. Intermediate (YE1/YE2)
3. Intermediate (ISRG Root YE)
4. Intermediate (ISRG Root X2)
5. Root CA (ISRG Root X1)

I guess the certs (3 & 4) are root certs themselves so Kestrel web server is dropping them from the chain.

None of my LE certs have these in chain so unable to test this scenario for now.