Run 2 SSL servers on 1 debian Pi, both FQDNs,1 Nginx 1 apache, wrong certificate, is this SNI issue?

Question

I'm forced to use Nginx on a.ddns.net and Apache for b.ddns.net (reverse proxy solution too tricky due to established setups). Real server names edited but both verified as resolving to same IP and SSL certs verified with OpenSSL.

Existing setups use IP vhosts respectively:

server {
            listen 192.168.1.174:443 ssl;          
            server_name a.ddns.net;
            root /var/www/html/a.ddns.net/;
            add_header Strict-Transport-Security "max-age=31536000";

            ssl on;
            ssl_session_cache builtin:1000 shared:SSL:10m;
            ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ;
            ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
            ssl_prefer_server_ciphers on;
    ssl_certificate /etc/letsencrypt/archive/a.ddns.net/cert1.pem;
    ssl_certificate_key /etc/letsencrypt/archive/a.ddns.net/privkey1.pem;

Apache2.4 sites-available/a.ddns.net.conf

SSLStrictSNIVHostCheck on
<VirtualHost 192.168.1.173:443>
        ServerAdmin webmaster@localhost
        ServerName b.ddns.net
        DocumentRoot /var/www/html/
        Alias /test /media/data/RPi1-Pictures
/media

    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    </IfModule>

        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/b.ddns.net/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/b.ddns.net/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf
        SSLVerifyClient none

dnsmasq (Pi-hole) and /hosts setup with domain names like this:

127.0.0.1 a.ddns.net b.ddns.net raspberrypi3.home localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.1.174 a.ddns.net
192.168.1.173 b.ddns.net

......

Within the LAN it works as expected since a and b domains appear in dnsmasq/hosts files, but when I try external test with dig/curl etc I hit SSL certificate issue which appears to show that a.ddns.net (Nginx) is not actually being resolved:-

curl https://a.ddns.net -v                         *   Trying 92.106.xxx.xx:443...                         * TCP_NODELAY set
* Connected to a.ddns.net (92.106.xxx.xx) port 443 (#0)
* ALPN, offering h2                                     * ALPN, offering http/1.1
* successfully set certificate verify locations:        *   CAfile: /data/data/com.termux/files/usr/etc/tls/cert.pem                                                      CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):       * TLSv1.3 (IN), TLS handshake, Server hello (2):        * TLSv1.2 (IN), TLS handshake, Certificate (11):        * TLSv1.2 (IN), TLS handshake, Server key exchange (12):* TLSv1.2 (IN), TLS handshake, Server finished (14):    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):                                                       * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):                                                     * TLSv1.2 (OUT), TLS handshake, Finished (20):          * TLSv1.2 (IN), TLS handshake, Finished (20):           * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256                                                    * ALPN, server accepted to use http/1.1
ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=b.ddns.net
*  start date: Oct 13 13:27:18 2019 GMT
*  expire date: Jan 11 13:27:18 2020 GMT
*  subjectAltName does not match a.ddns.net
* SSL: no alternative certificate subject name matches target host name 'a.ddns.net'
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name

I thought the above setup would be an easier fix than creating a complex reverse proxy because I understood that dnsmasq with SNI on both Apache and Nginx would able the correct server to be resolved from the client URL. What am I missing?

Is alternate or maybe easier solution to edit SSL cert with a SAN i.e. add a.ddns.net to b.ddns.net?

Thanks for any guidance

score 1 · Answer 1 · answered Oct 21 '19 at 14:09

1

I think you are missing an essential piece of your setup. While you show the internal configuration of the server which has different internal IP addresses for the two servers and you explain the external configuration where both domains have the same IP address, you don't explain how the mapping from the external IP address to the correct internal IP address is done.

My guess is that you do a simple port forwarding from the external IP address to the internal IP address of one of the servers (for b.ddns.net, i.e. Apache). And because of this it will always access only Apache which has no configuration for a.ddns.net.

One way to solve this issue is to have only a port forwarding to nginx which then has a configuration for both domains. Since you need Apache for one domain nginx could be configured to be a reverse proxy for this domain and forward (not redirect!) everything to the internal Apache.

answered Oct 21 '19 at 14:09

Steffen Ullrich

13,227
27
39

Thanks Steffen, I hadn't explored nginx to forward everything back to apache, this might be best solution. – awsbarker Oct 21 '19 at 14:19
[ran over 5 minute edit timelimit], I do use router portforward 80/443 to 192.168.1.173 which is b.ddns.net but I thought dnsmasq enabled both .173 and .174 to accept 80/443 equally. – awsbarker Oct 21 '19 at 14:25
@awsbarker: dnsmasq cares about mapping from name to IP. Since you port forward explicitly to the IP of Apache it will use Apache. There is no DNS involved in this port forwarding. You would need to have some kind of dynamic mapping which already maps on your router based on the SNI in the ClientHello. But routers usually (always?) don't provide such capability. – Steffen Ullrich Oct 21 '19 at 14:36

Run 2 SSL servers on 1 debian Pi, both FQDNs,1 Nginx 1 apache, wrong certificate, is this SNI issue?

1 Answers1