Shortname/Netbios not redirecting

Help
1

1. Caddy version (caddy version):

v2.4.1 h1

2. How I run Caddy:

Binary on Ubuntu with Caddyfile

a. System environment:

Ubuntu 20

b. Command:

caddy reload --config /etc/caddy/Caddyfile

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

https://shortname, http://shortname {
        redir https://shortname.MY.FULL.DOMAIN.HERE{uri} 308


vault.MY.FULL.DOMAIN.HERE {
        tls /etc/caddy/tls/CertPem.pem /etc/caddy/tls/KeyNpw.pem
        reverse_proxy localhost:8200

3. The problem I’m having:

I have a listener set up for a shortname/netbios name. If I type a shortname into my browser, like website/, my device should send that request to website.my.full.domain.here. This all works correctly on other web servers, like IIS and Apache2, that I’ve set up myself. I’m trying to replicate the same in Caddy, but when I put the shortname in my browser, I get an SSL error. Firefox says: Error code: SSL_ERROR_INTERNAL_ERROR_ALERT for example, and no redirect happens. My proper domain with internal certs works fine otherwise. I wanant to redirect to the FQDN so people don’t have to click through certificate errors. My CA Chain is trusted on all devices that would access this site.

4. Error messages and/or full log output:

There is no error or access logs.

5. What I already tried:

I’ve tried a dozen different permutations, including the one example on google of someone trying the same thing. He said it worked for him, it doesn’t for me.

6. Links to relevant resources:

2

Are you sure? There’s always logs. When running as a systemd service, you can see them like this:

journalctl -u caddy --no-pager | less

Also, your Caddyfile seems to have invalid syntax. Please don’t omit any parts of your config.

1 Like
3

I mean there are logs, but none that relate to this connection. There isn’t even an access log as far as I can see. I think my Caddyfile has the correct syntax, I just didn’t copy it out properly:

{
        default_sni vault.MY.DOMAIN.HERE.COM
}


https://vault, http://vault {
        redir https://vault.MY.DOMAIN.HERE.COM{uri} 308
        log {
                output file /tmp/caddylogs/access.log
                }
}

vault.OTHER.DOMAIN.UK {
        redir https://vault.MY.DOMAIN.HERE.COM{uri}
}

vault.MY.DOMAIN.HERE.COM {
        tls /etc/caddy/tls/vaultCertPem.pem /etc/caddy/tls/vaultKeyNpw.pem
        reverse_proxy localhost:8200
}

I’ve also noticed if I put the certificate under the shortname block, I don’t get the internal error in the browser. I just get a generic SSL error that you have to accept (because the certificate isn’t valid and can’t ever be valid for a shortname) and then the redirect works okay. Same if I use the self-signed certs.

4

Try enabling debug mode to get more logs.

5

When running as a systemd service, the systemd config has PrivateTmp=true, so the files written to /tmp actually end up in a location like /tmp/systemd-private-<some-hash>-caddy.service-<some-hash>/tmp, so each service gets their own isolated /tmp.

Right - because otherwise Caddy would try to fetch a certificate for that name from a public CA, and fail because that’s not a real domain.

6

I enabled debug and can see a log:

"http.stdlib","msg":"http: TLS handshake error from 192.168.128.13:65391: no certificate available for 'vault'"

Maybe I’m misunderstanding something, but why would it be showing that, or any, certificate? Shouldn’t it just be redirecting the request to the FQDN and presenting the certificate assigned to that FQDN block? My middle example, vault.OTHER.DOMAIN.UK, doesn’t have a cert assigned, manually or by LE, and it redirects as expected to my other FQDN and shows the correct certificate.

I found the example someone else had where they got it working, that I’ve tried to replicate: ERR_SSL_PROTOCOL_ERROR when using search domain to complete domain name I’m not sure if this person is missing something from their config snippet that works because it looks like they’ve duplicated the snippet above they said doesn’t work. I don’t think the {$DOMAIN} part being different should matter because I believe that’s just a pre-assigned environment variable?

7

Making requests over HTTPS requires the TLS handshake to complete to result in a response. If there’s no certificate, then the TLS handshake cannot complete, therefore the server never handles the request.

Are you sure? Caddy may have had one issued from Let’s Encrypt or ZeroSSL. Check Caddy’s storage, and check your logs from previous runs to see if it issued one.

They’re only doing it over HTTP, not HTTPS. It’s not possible to serve HTTPS without a certificate.

8

Okay, I think I’m just being turbodumb. For some reason, I thought I had this exact setup working in Apache2 and IIS, but I just checked those sites again and when explicitly using https with a shortname and they both throw cert errors. I was thrown on this one because I was originally testing in Chrome and Firefox, but then swapped to only using Firefox at some point after I fixed the http://vault redirect. Firefox seems to be forcing https://vault, even when I type http://. If I just type vault/ or http://vault/ - or the IP now i’ve changed the listener to just :80 - into Chrome, the redirect works as expected. Not sure why Firefox is doing that for this web server because I don’t have force https enabled, and it doesn’t do it for those other sites on IIS and Apache2.

Not really sure if there’s anything I can do about this? I could technically issue a cert with a shortname as the SAN from my CA but I’m pretty sure browsers haven’t trusted shortnames for years, even with a valid certificate. I guess it’s just the woes of hosting on-prem.

Also, the server doesn’t have internet access, so LE wouldn’t have ever worked. My OTHER.DOMAIN.UK block was working because when I automated cert requests for our CA, I included SANs for both hostnames, so you’d get a valid cert and the redirect would work anyway.

1 Like
9

Might be this:

10

This topic was automatically closed after 30 days. New replies are no longer allowed.