[Resolved] SSL + Routing Issues - Apache Config Problem

[MBfromOK]

To start: Thanks everyone for your hard work on OPNSense, I moved from a XenServer host running distinct servers for DHCP, DNS, Firewall, and NextCloud to a ProxMox Host with just OPNSense (19.1.1) and NextCloud.

So much simpler to update and maintain, much easier to secure, looks so much nicer!

Network Details:
    VM Host: 2 NICs - 1 WAN, 1 LAN
        OPNSense (19.1.1) has 2 Virtual NICs - 1 WAN & 1 LAN running DHCP, DNS, NTP, and Firewall
        Webserver is Debian 9 running Apache 2.4.25 - 1 NIC, Internal Only 10.x.x.x IP

    Existing (internal) network was established with <mydomainname>.local when it was created 2 years ago, purchased <mydomainname>.space in the last 2 weeks.
    DNS is working and all servers are accessible internally from either their IP or DNS.

To the Issue at hand:

• I am trying to connect several (internal) web pages to the internet around / through OPNSense.
  
• I would like internal requests to route internally, external to route as needed
  
• I have created and configured the web server with Let's Encrypt certificates for all web pages.
• I have verified that my ISP blocks incoming port 80 traffic (made getting the certificates a pain!)
• I have attempted the steps listed here: https://forum.opnsense.org/index.php?topic=8783.0 and here: https://forum.opnsense.org/index.php?topic=6155.0 to resolve this myself
• At one point (before I setup the certificates) I was able to connect to my NextCloud via the WAN using my cellular data, but the LAN had no access to the internet so I reverted it.
• Now, when I load an https url it is giving me either:

(mycloud.<mydomain>.space or www.<mydomain>.space)

Error details:

Code: [Select]

This site can’t provide a secure connection mycloud.<mydomain>.space didn’t accept your login certificate, or one may not have been provided.
Try contacting the system admin.
ERR_BAD_SSL_CLIENT_AUTH_CERT
Advanced details:
This error refers to the OPNSense self signed certificate, though now I can't figure out where I saw that reflected.

~OR~

(<mydomain>.space)
Error details:
   

Code: [Select]

Your connection is not private
Attackers might be trying to steal your information from <mydomain>.space (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
   
Advanced details:
   

Code: [Select]

This server could not prove that it is <mydomain>.space; its security certificate is from mycloud.<mydomain>.space. This may be caused by a misconfiguration or an attacker intercepting your connection.
   
Any help the community can offer would be great, hoping to take this and make a how-to for the docs.

[newsense]

The CN and/or SANs you're using on the public cert must match mycloud.mydomain.space in your example.

For public certs the SANs are what matters nowadays, so at the very least make sure your CN and SAN are defined as you can see in the forum.opnsense.org certificate.

[newsense]

Also please edit your thread title to something that resembles SSL Issue - as it stands is highly misleading 

[MBfromOK]

I will check that I didn't get my certificates switched for the <mydomain).space error, what about the first one (where it seems that OPNSense is intercepting / not routing the address)?

[MBfromOK]

The CN and/or SANs you're using on the public cert must match mycloud.mydomain.space in your example.

For public certs the SANs are what matters nowadays, so at the very least make sure your CN and SAN are defined as you can see in the forum.opnsense.org certificate.

Am I correct regarding the following?

Subject / CN = Common Name
SAN = Subject Alternative Name

[newsense]

That is correct. Note that you can have one or more SANs, most common being hostname + fqdn.

[newsense]

what about the first one (where it seems that OPNSense is intercepting / not routing the address)?

Something doesn't add up here, you're mentioning port forwarding tutorials then asking about SSL intercept.

Which is the actual setup that you have in place right now ?

[MBfromOK]

DHCP Cable Internet connection with Port 80 blocked (ISP)

Dynamic DNS (EntryDNS) pointing to my dynamic Public IP Address with domain <mydomain>.space

I am trying to route <mydomain>.space to a webspace hosted by my internal webserver living at ip: 10.2.6.4 with the (current) hostname of mycloud.<mydomain>.local

When I try (from inside my private network) to access https://<mydomain>.space I get this error:
This site can’t provide a secure connection <mydomain>.space didn’t accept your login certificate, or one may not have been provided.
Try contacting the system admin.
ERR_BAD_SSL_CLIENT_AUTH_CERT

Digging through the error indicates that the issue is being caused by a self signed certificate.  The only certificates on this server are the Let's Encrypt certificates I created and the OPNSense WebGUI Certificate (self signed).  I mention ssl intercept because (opnsense.<mydomain>.local is applying its certificate to <mydomain>.space and I am talking about port forwarding because I am not sure if the issue is happening because forwarding is broken or OPNSense.

[newsense]

In short, neither opnsense nor port forwarding are "broken".

You seem to be a bit confused about how SSL actually works however.

What cert do you see connecting from outside to https://domain.space and what cert do you receive when connecting from inside to https://server_IP ?

Also, you can safely remove the OPNSense WEBGUI cert from that server, it's utterly irrelevant to the whole setup.

[MBfromOK]

It would seem my Apache configuration was broken while trying to get certbot to validate my domain through the blocked http port (80).

The Resolution:
I removed, purged, and reinstalled apache, then restored my NextCloud instance and now the root domain, www domain, and cloud domain all load the correct certificate, but at the default document root.  I am working on that now.

To answer your question:

• mycloud.<mydomain>.space and www.<mydomain>.space both were showing the unsigned OPNSense certificate (from a completely different server)
• <mydomain>.space was reporting that it wasn't in the domain list for mycloud.<mydomain>.space's certificate.

I validated the certificate path and filenames for all three domains, revoked and reissued them multiple times, restarted the server and apache several times and couldn't resolve it.

As far as the unsigned OPNSense Certificate is concerned, it was created by OPNSense during the install; even though it is non-validated security, I don't think I will be taking your advice to remove it (unless I choose to give it a validated cert as well).

Thanks again for your time, sorry that it ended up not related to OPNSense after all... One thing these forums don't accurately reflect is the amount of time involved for the post creator. I was hitting my head on the wall for over 30 hours trying to figure the certificate error and routing issues before I started this post. This was created when (tunnel vision) seemed to indicate all roads pointed to OPNSense.