From 3b7f26741319c53eda3a4c44360e3d5e7664a3c3 Mon Sep 17 00:00:00 2001
From: Anthony Ettinger <anthony@chovy.com>
Date: Mon, 3 Aug 2026 09:59:08 +0000
Subject: [PATCH] fix(origin): serve port 80 instead of redirecting to a
 certificate nobody can verify
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The template redirected :80 to :443, with a comment saying the only
problem was a missing 443 block. That reasoning was incomplete: it
assumes the client can verify what it lands on, and the two biggest
classes cannot.

No CA will issue for an ending outside the DNS root, so the 443 block
presents a self-signed certificate. TronBrowser, moshpit-proxy and the
SDKs check it against the registry's published pin and are fine. curl and
a stock browser have no pin to check, so they reject it — and the
redirect leaves them nowhere:

    curl chovy.hacker -L
    curl: (60) SSL certificate problem: self-signed certificate

Through the gateway it is worse: pit.moshcode.sh forwards the status and
not the Location, so a visitor gets a 301 pointing nowhere at all.

Now :80 serves the site. Both ports serve it, neither redirects to the
other, and each client takes the one it can verify — pin-checking clients
still get TLS, everyone else gets the page instead of an error that reads
as "Moshpit is broken".

HTTPS-only remains right for a name in the public DNS. It is not
available for a name outside it, and pretending otherwise costs the
visitor the site.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 nginx/moshpit-origin.conf | 43 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/nginx/moshpit-origin.conf b/nginx/moshpit-origin.conf
index 3c9c456..7d272c5 100644
--- a/nginx/moshpit-origin.conf
+++ b/nginx/moshpit-origin.conf
@@ -18,11 +18,44 @@ server {
     listen [::]:80;
     server_name NAME;
 
-    # Keep this. Upgrading to HTTPS is right, and it was only ever a problem
-    # when there was no 443 block for the name to land on — which produced a
-    # certificate for whatever the default vhost happened to hold, and an error
-    # that looks like Moshpit is broken when it is nginx that is misconfigured.
-    return 301 https://$host$request_uri;
+    # This used to redirect to HTTPS, with a comment saying the only problem
+    # was a missing 443 block. That reasoning was incomplete: it assumes the
+    # client can verify what it lands on, and the two biggest classes cannot.
+    #
+    # No CA will issue for an ending outside the DNS root, so the 443 block
+    # below presents a self-signed certificate. TronBrowser, moshpit-proxy and
+    # the SDKs check it against the registry's published pin and are happy.
+    # `curl` and a stock browser have no pin to check against, so they reject
+    # it — and a redirect gives them no way back:
+    #
+    #     curl chovy.hacker -L
+    #     curl: (60) SSL certificate problem: self-signed certificate
+    #
+    # Through the gateway it is worse. pit.moshcode.sh forwards the status and
+    # not the Location, so a visitor gets a 301 pointing nowhere at all.
+    #
+    # So port 80 serves the site instead. Both ports now serve it, neither
+    # redirects to the other, and each client takes the one it can verify —
+    # pin-checking clients still get TLS, and everyone else gets the page
+    # rather than an error that reads as "Moshpit is broken".
+    #
+    # HTTPS-only is still the right default for a name in the public DNS. It
+    # is not available for a name outside it, and pretending otherwise costs
+    # the visitor the site.
+
+    access_log /var/log/nginx/NAME.access.log;
+    error_log  /var/log/nginx/NAME.error.log warn;
+
+    root /var/www/NAME;
+    index index.html;
+
+    location / {
+        try_files $uri $uri/ =404;
+    }
+
+    location ~ /\. {
+        deny all;
+    }
 }
 
 server {