Odd problem with DoH and DoT

[Eric Germann]

I’m having a really weird issue with 9.18.3

When I connect with OpenSSL to this particular server, I get two different server certs

Here is my requisite configs

        listen-on               port 53 { any; };
        listen-on               port 443 tls local-tls http local-http-server { any; };
        listen-on               port 853 tls local-tls { any; };
        listen-on-v6            port 53 { any; };
        listen-on-v6            port 443 tls local-tls http local-http-server { any; };
        listen-on-v6            port 853 tls local-tls { any; };
        http-port               80;
        https-port              443;
};

tls local-tls {
    key-file  "/etc/namedb/keys/privkey.pem";
    cert-file "/etc/namedb/keys/fullchain.pem";
};

http local-http-server {
    endpoints { "/dns-query";  };
};

my last line of the cert in fullchain.pem for the correct server cert is

"+sWJ8Oluyktfz7I5MSsXwIqCMK/4qG/S4hf04FUk"


When I connect to port 443 for DoH, I get a server cert that ends in “FUk”

When I connect to port 853 for DoT, I get a server cert that ends in “HhQraavJaViojiiFyfcKONWCPVuQozJDWoICan7i”.  The issue is when I execute

kdig -d @ns05x.semperen.com +tls-sni=ns05x.semperen.com +tls-host=ns05x.semperen.com semperen.com mx

I get back 

;; DEBUG: Querying for owner(semperen.com.), class(1), type(15), server(ns05x.semperen.com), port(853), protocol(TCP)
;; DEBUG: TLS, imported 127 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=ns05x.semperen.com
;; DEBUG:      SHA-256 PIN: WLEeS4l9ObJUnZ1X055NrxlYkzaep5Ynig7KA8GnuqE=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=R3
;; DEBUG:      SHA-256 PIN: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
;; DEBUG:  #3, C=US,O=Internet Security Research Group,CN=ISRG Root X1
;; DEBUG:      SHA-256 PIN: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is NOT trusted. The certificate chain uses expired certificate. 
;; WARNING: TLS, handshake failed (Error in the certificate.)
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=ns05x.semperen.com
;; DEBUG:      SHA-256 PIN: WLEeS4l9ObJUnZ1X055NrxlYkzaep5Ynig7KA8GnuqE=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=R3
;; DEBUG:      SHA-256 PIN: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
;; DEBUG:  #3, C=US,O=Internet Security Research Group,CN=ISRG Root X1
;; DEBUG:      SHA-256 PIN: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is NOT trusted. The certificate chain uses expired certificate. 
;; WARNING: TLS, handshake failed (Error in the certificate.)
;; ERROR: failed to query server ns05x.semperen.com at 853(TCP)


Which says the cert is expired.  When checking the cert with OpenSSL that is returned, the start and end dates are the same, Jul 4 2022.

In the LetsEncrypt dir, in “archive” dorectory fullchain7.pem is the current cert and the symbolic link in “live” is linked to this.  However, that tail end of the incorrect server cert is contained in "fullchain5.pem”, and it is expired.  I relinked the files to make sure it wasn’t a file system issue.  How is it picking up the wrong full chain when I point it to a dir with only the links to chain7?

Querying ns04x.semperen.com returns the same cert on both ports.

Thanks for any pointers

--
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Medium: https://ekgermann.medium.com 
Twitter: @ekgermann
Telegram || Signal || Skype || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1