401 no ticket; a cookie that didn’t feel secure

After a long journey battling stubborn firewalls and DNS proxies, my homelab was finally starting to hum. I could access all my services using friendly `.homelab` addresses, my network-wide ad-blocking was working, and everything was looking rosy. I moved on to the final piece of the puzzle: getting my Proxmox server accessible through its own pretty URL, something like `https://proxmox.homelab`.

My plan was simple. I’d just add another server block to my Nginx reverse proxy configuration. I’d point it to my Proxmox server’s IP address and port 8006, add the usual set of proxy headers to make sure the connection passed through cleanly, and a little `proxy_redirect off` for good measure. A quick test with `nginx -t`, a graceful reload, and I was off to the races.

Except… I wasn’t.

My browser loaded the login page just fine, but every time I entered my username and password, I was greeted with the same ominous, two-word error message: “Connection error 401: No ticket.”

What? My password was right. I could log in with the IP address just fine. The authentication server was obviously working. So why was Nginx failing? I checked the logs. Nothing. No error in Nginx. The connection was being established, but the login was failing. It was as if I was going to a concert with a valid ticket, but the bouncer at the door couldn’t see it.

My first thought was that my Nginx configuration was stripping a crucial header. I meticulously reviewed every line, comparing it to working configs for other services. They all looked perfect. I tried every permutation of `proxy_set_header` I could find. Nothing. Then I thought maybe it was a caching issue. I cleared my browser’s cache, then my local DNS cache, then I used a different browser entirely. Still, nothing.

Frustration began to set in. How could a simple reverse proxy fail in such a specific way? The error wasn’t a timeout, a misdirection, or a failed connection. It was a failure of the login process itself.

The answer, I eventually discovered, was buried in the fine print of the developer console. I was watching the request headers for the login attempt when I noticed a tiny little flag on the authentication cookie: **Secure**.

Aha!

That simple, six-letter word was the key to the entire mystery. The `Secure` flag meant that the cookie would **only** be transmitted over an encrypted HTTPS connection. When my browser first connected to my Nginx proxy, it was using an insecure HTTP connection, because that’s all I had configured for the proxy. The browser, following its own strict rules, saw this and said, “Nope, no cookies for you,” and never sent the authentication ticket.

The solution was clear, but not simple. My Nginx proxy had to serve the page over HTTPS. But how? My Proxmox server’s own certificate was self-signed, and I had no interest in setting up an entire Certificate Authority just for my homelab.

Thankfully, the community had already figured out the perfect workaround. My Proxmox server, the host, already had a perfectly good self-signed certificate and private key. All I had to do was copy those two files from my host machine into my Nginx container, a simple task with a tool like `pct push`.

Once the certificates were in place, I configured Nginx to serve the page over HTTPS using those very files. I added the necessary `listen 443 ssl` directives and pointed it to the correct file paths. With one final `nginx -t` to check my work and a `nginx -s reload`, I reloaded the page.

And there it was. No more error. I entered my credentials, and this time, the cookie was sent. The bouncer saw my ticket, the door opened, and I was granted entry. The `proxmox.homelab` URL was finally working.

It was a tough battle, one that tested my patience and forced me to delve into a level of network detail I hadn’t expected. But in the end, the system is now more secure, more robust, and more reliable. And I know the hard-won lesson: when you’re dealing with a reverse proxy, you’re not just a middleman; you’re an entire authentication gateway, and sometimes, you need a little digital paper trail to prove it.

Leave a Reply

Your email address will not be published. Required fields are marked *

recaptcha placeholder image
 

This site uses Akismet to reduce spam. Learn how your comment data is processed.