My VPS operates on LAN/NAT, and I can access both the ApisCP dashboard (ports 2082/2083) and the websites I’ve created (ports 80/443). The Let’s Encrypt SSL works perfectly for the main dashboard domain on port 2083.
However, I need help with the SSL for user websites. The system indicates “Certificate Detected,” valid from 2024/10/30 to 2025/01/28.
In the file /etc/httpd/conf/virtual/site1, I see these lines:
And I’ve confirmed that those certificate files exist.
Actual Behavior
Despite this, when I visit https://user-domain.com, the SSL certificate loading in my browser is the one from the ApisCP dashboard domain, not the intended user-domain.com certificate. I also tried creating another user and website/domain but encountered the same SSL issue.
What does htrebuild report from the command-line? When installing a SSL certificate, there’s a 2 minute delay to elide successive HTTP reloads. Once that timer elapses, the new configuration is compiled and Apache restarted.
Based upon the server returning the server certificate, which is a fallthrough case if SSL is unmatched, either Apache couldn’t reload - htrebuild will notify you if so or the IP address for the site (ipinfo,nbaddrs service value in Nexus) isn’t matching with the IP you’re accessing it as while behind the NAT. See also NAT.md.
This VPS has a single IP; the user websites can be accessed on ports 80 and 443 (but with SSL error). So, the NAT is not the cause.
But I saw another issue and don’t know if it can affect this case.
My NAT has the gateway IP xxx.xxx.xxx.229, which goes to a pfsense.
During the ApisCP installation, the gateway IP was automatically used as the server address.
Yes, this is how Apache resolves virtualhosts. When no named servername/serveralias + IP:PORT combination matches, it falls through to the server VirtualHost. Take for example, apiscp.com; for me it’s in /etc/httpd/conf/virtual/site1:
In order for this container to match, a HTTP request for “apiscp.com” must arrive on the interface that binds 64.22.68.70. Moreover, the HTTP request must have originated from a connection opened to 64.22.68.70. If I were to access it within my LAN and let’s say in I have an override in my hosts file for apiscp.com to 192.168.1.30, then this wouldn’t match because the destination IP of the request uses 192.168.1.30, which doesn’t match.
NB: Likewise the same container is matched if the HTTP hostname is panel.dev.
That’s correct behavior. The IP address shown is the publicly reachable one, not internal.
Same scenario, nomenclature is different. There’s a single public IP (xxx.xxx.xxx.228), it passes through your router, then the IP is translated into the internal network address (192.168.1.132).
Here’s how I understand your network setup:
Here’s a simple test to run on a machine outside your network:
This should complete without a SSL warning. If it does, then you have an issue within your NAT accessing the server from a local desktop. If it does not, then there’s an issue with pfSense forwarding the packets to your server, specifically it’s connecting to the server on an IP other than 192.168.1.132.
Out of curiosity, is the SSL Organization listed under Web > SSL Certificates listed as “Let’s Encrypt - E5” for the account? Tracking a separate issue, which I think may be related to yours.
This test was intended to avoid dealing with NAT and pfsense issues.
Using the private IP in the curl command and loading the HTTP://, we get the correct website.
Using HTTPS://, we get the SSL error.
Run htrebuild. There’s a 2 minute delay when configuration is compiled down, so it’s possible you rebooted before this had time to process. The remarkable change is that in, for example /etc/httpd/conf/virtual/site1, the following line:
Include /etc/httpd/conf/site1 SSLEngine On
SSLCertificateKeyFile /home/virtual/site1/fst//etc/httpd/conf/ssl.key/server.key
is correctly rendered as:
Include /etc/httpd/conf/site1
SSLEngine On
SSLCertificateKeyFile /home/virtual/site1/fst//etc/httpd/conf/ssl.key/server.key
