File or directory not found in TLS directive

If Let’s Encrypt does not allow it do you have other way to overcome my setup: using HTTPS with a local domain name not PSL conforming?

You can issue your own certificate but it won’t be publicly trusted, by adding this to your site block:

tls internal

I made use of the ‘tls internal’ and got this from Caddy log …

{"level":"info","ts":1687403536.5371983,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
{"level":"info","ts":1687403536.537252,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["zung102-olympic.nord"]}
{"level":"info","ts":1687403536.539026,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1687403536.539404,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1687403536.5394282,"msg":"serving initial configuration"}
{"level":"info","ts":1687403536.540136,"logger":"tls.obtain","msg":"acquiring lock","identifier":"zung102-olympic.nord"}
{"level":"info","ts":1687403536.5438573,"logger":"tls.obtain","msg":"lock acquired","identifier":"zung102-olympic.nord"}
{"level":"info","ts":1687403536.5440812,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"zung102-olympic.nord"}
{"level":"info","ts":1687403536.545544,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"zung102-olympic.nord"}
{"level":"info","ts":1687403536.5456305,"logger":"tls.obtain","msg":"releasing lock","identifier":"zung102-olympic.nord"}
{"level":"warn","ts":1687403536.5462217,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [zung102-olympic.nord]: no OCSP server specified in certificate","identifiers":["zung102-olympic.nord"]}

However I got this error when using HTTPS …

zung102-olympic.nord sent an invalid response.

  • [Try running Windows Network Diagnostics](javascript:diagnoseErrors()).

ERR_SSL_PROTOCOL_ERROR

if using HTTP then Vaultwarden login page came up fine.

Why did HTTPS fail?

Don’t use browsers to troubleshoot.

What does a curl -v request for your domain tell you?

I’m guessing, 99%, that it’s because the certificate isn’t trusted. If so, you’ll need to make sure your host trusts the root Caddy generated in your container.

Firstly, thank you for the incredible support and help from you guys and for being patient with me.

I have restarted Caddy container again and got these errors …

{"level":"info","ts":1687447037.8745723,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"warn","ts":1687447038.0703156,"logger":"pki.ca.local","msg":"installing root certificate (you might be prompted for password)","path":"storage:pki/authorities/local/root.crt"}
{"level":"info","ts":1687447038.0743916,"msg":"warning: \"certutil\" is not available, install \"certutil\" with \"apt install libnss3-tools\" or \"yum install nss-tools\" and try again"}
{"level":"info","ts":1687447038.074617,"msg":"define JAVA_HOME environment variable to use the Java trust"}
{"level":"error","ts":1687447038.095018,"logger":"pki.ca.local","msg":"failed to install root certificate","error":"failed to execute update-ca-certificates: exit status 1","certificate_file":"storage:pki/authorities/local/root.crt"}
{"level":"info","ts":1687447038.095376,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
{"level":"info","ts":1687447038.095602,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"info","ts":1687447038.0956967,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
{"level":"info","ts":1687447038.0957139,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
{"level":"info","ts":1687447038.0957224,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["zung102-olympic.nord"]}
{"level":"warn","ts":1687447038.101214,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [zung102-olympic.nord]: no OCSP server specified in certificate","identifiers":["zung102-olympic.nord"]}
{"level":"info","ts":1687447038.104262,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1687447038.1044781,"msg":"serving initial configuration"}
{"level":"info","ts":1687447038.1103811,"logger":"tls","msg":"finished cleaning storage units"}

It appeared there was an issue with permission since I can find “root.crt” here …

zung25@zung-1:~/docker/caddy$ sudo ls -l caddy_data/caddy/pki/authorities/local
total 16
-rw------- 1 root root 676 Jun 22 02:49 intermediate.crt
-rw------- 1 root root 227 Jun 22 02:49 intermediate.key
-rw------- 1 root root 631 Jun 22 02:49 root.crt
-rw------- 1 root root 227 Jun 22 02:49 root.key

Following Matt’s suggestion …

 curl -v zung102-olympic.nord
*   Trying 100.122.127.103:80...
* Connected to zung102-olympic.nord (100.122.127.103) port 80 (#0)
> GET / HTTP/1.1
> Host: zung102-olympic.nord
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://zung102-olympic.nord/
< Server: Caddy
< Date: Thu, 22 Jun 2023 15:51:46 GMT
< Content-Length: 0
< 
* Closing connection 0
1 Like

Those errors are saying that Caddy didn’t have permission to install the root CA cert (because it’s running as a non-root user without those permissions). To do that, run sudo caddy trust, which will perform the trust installation as root instead.

You only made an HTTP request, and Caddy served you a redirect to HTTPS. See the Location header, which instructs the client to try again, at a different address. You can use the -L flag to follow the Location header redirect, or you can just do curl -v https://zung102-olympic.nord instead.

1 Like

I do not have caddy binary to run sudo caddy trust …and

sudo docker exec caddy caddy trust
{"level":"warn","ts":1687451802.4255006,"msg":"installing root certificate (you might be prompted for password)","path":"localhost:2019/pki/ca/local"}
{"level":"info","ts":1687451802.426099,"msg":"warning: \"certutil\" is not available, install \"certutil\" with \"apt install libnss3-tools\" or \"yum install nss-tools\" and try again"}
{"level":"info","ts":1687451802.4261234,"msg":"define JAVA_HOME environment variable to use the Java trust"}
Error: failed to execute update-ca-certificates: exit status 1

what else can I try ?

curl -v https://zung102-olympic.nord
*   Trying 100.122.127.103:443...
* Connected to zung102-olympic.nord (100.122.127.103) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

I also tried to start caddy container with sudo (sudo docker compose up -d) but got same errors.

1 Like

Oh you’re in Docker, sorry. Instructions for that are here: Keep Caddy Running — Caddy Documentation

1 Like

tried this …

sudo docker compose cp     caddy:/data/caddy/pki/authorities/local/root.crt     /usr/local/share/ca-certificates/root.crt   && sudo update-ca-certificates
[+] Copying 1/0
 ✔ caddy copy caddy:/data/caddy/pki/authorities/local/root.crt to /usr/local/share/ca-certificates/root.crt Copied0.0s 
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

however got new errors …

curl -v https://zung102-olympic.nord:8080
*   Trying 100.122.127.103:8080...
* Connected to zung102-olympic.nord (100.122.127.103) port 8080 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* (5454) (IN), , Unknown (72):
* error:0A00010B:SSL routines::wrong version number
* Closing connection 0
curl: (35) error:0A00010B:SSL routines::wrong version number

I have searched around wrong version number solution but nothing exactly matching my case

Why are you making a request to port 8080? Your docker-compose.yml had Caddy bound to port 443 for HTTPS.

Sorry for the confusion. I am experimenting 2 instances of vaultwarden containers with Caddy container concurrently One instance has Caddy reverse proxy on public accessible domain name (mapped to public IP address) and it worked as expected with HTTPS. The other instance attempted to reverse proxy on localhost with TLS internal on local domain name -zung102-olympic.nord- (mapped to local IP address) and hopefully works with HTTPS. For the second instance I must use 8080:80 to avoid the collision with the 1st one.

Now I just ran one instance of vaultwarden (80:80) and use TLS internal for local HTPPS. Below are the results from curl command…

curl -v https://zung102-olympic.nord 
*   Trying 100.122.127.103:443...
* Connected to zung102-olympic.nord (100.122.127.103) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: [NONE]
*  start date: Jun 22 19:21:59 2023 GMT
*  expire date: Jun 23 07:21:59 2023 GMT
*  subjectAltName: host "zung102-olympic.nord" matched cert's "zung102-olympic.nord"
*  issuer: CN=Caddy Local Authority - ECC Intermediate
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x561e0a27a560)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: zung102-olympic.nord
> user-agent: curl/7.81.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 308 
< alt-svc: h3=":443"; ma=2592000
< date: Fri, 23 Jun 2023 02:37:47 GMT
< location: https://zung102-olympic.nord/
< strict-transport-security: max-age=31536000;
< x-frame-options: DENY
< x-robots-tag: none
< x-xss-protection: 1; mode=block
< content-length: 0
< 
* Connection #0 to host zung102-olympic.nord left intact

Should I expect the contents of the web page?

From a browser I got this error ERR_TOO_MANY_REDIRECTS

That’s particularly weird. I don’t see Server: Caddy in here, so I don’t think Caddy handled the request.

Oh, you removed the Server header. Please don’t do that, it makes debugging harder. It doesn’t increase security in any way. If it was harmful at all, we wouldn’t enable it in the first place. It’s a very useful header to see which servers a request passed through.

1 Like

Below are my setup and if you can detect any mistake …

  1. Vaultwarden docker-compose.yml
services:

  vaultwarden:
    image: vaultwarden/server
    container_name: vaultwarden
    hostname: vaultwarden
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./vaultwarden_data/:/data/
    expose:
      - 80:80
      - 3012:3012

networks:
  default:
    name: $DOCKER_MY_NETWORK
    external: true
  1. Caddy docker-compose.yml
services:

  caddy:
    image: caddy
    container_name: caddy
    hostname: caddy
    restart: unless-stopped
    env_file: .env
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./caddy_config:/config
      - ./caddy_data:/data
      - /etc/ssl/certs:/etc/ssl/certs:ro
      - ./site:/srv

networks:
  default:
    name: $DOCKER_MY_NETWORK
    external: true
  1. the .env file
# GENERAL
TZ=North America/Toronto
DOCKER_MY_NETWORK=caddy_net
  1. The Caddyfile
{$MY_DOMAIN2} {
  encode gzip

  # Uncomment to improve security (WARNING: only use if you understand the implications!)
  # If you want to use FIDO2 WebAuthn, set X-Frame-Options to "SAMEORIGIN" or the Browser >
  header {
       # Enable HTTP Strict Transport Security (HSTS)
       Strict-Transport-Security "max-age=31536000;"
       # Enable cross-site filter (XSS) and tell browser to block detected attacks
       X-XSS-Protection "1; mode=block"
       # Disallow the site to be rendered within a frame (clickjacking protection)
       X-Frame-Options "DENY"
       # Prevent search engines from indexing (optional)
       X-Robots-Tag "none"
      
  }
 # tls  /etc/ssl/certs/_wildcard.zung102-olympic.nord.pem  /etc/ssl/certs/_wildcard.zung10>
#  acme_server
  tls internal

  # Notifications redirected to the websockets server
  reverse_proxy /notifications/hub localhost:3012  

  # Proxy everything else to Rocket
  reverse_proxy localhost:80  {   # 100.122.127.103:80  {
       # Send the true remote IP to Rocket, so that vaultwarden can put this in the
       # log, so that fail2ban can ban the correct IP.
       header_up X-Real-IP {remote_host}
  }
)

here is a portion of caddy_net

   "Containers": {
            "3dbe05e15c5e70da8f067f33853386772b758db0b46451e5afefb61df5f5526e": {
                "Name": "caddy",
                "EndpointID": "ac1c1fc3be36e56351a745515d5f5143decedb41086386d9b8cdca04faf3fa0f",
                "MacAddress": "02:42:ac:12:00:03",
                "IPv4Address": "172.18.0.3/16",
                "IPv6Address": ""
            },
            "f73fcd2287483602b4a9b8ce364818317fe83919450ff9f76c20cb93356c65e3": {
                "Name": "vaultwarden",
                "EndpointID": "47deb3cc9ff5256b991e2b873a26c754934b0fc2c02c28235fbfbba1f44ae2b2",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },

If I took down Caddy container I got this …

docker compose down
[+] Running 1/1
 ✔ Container caddy  Removed                                                           0.3s 
zung25@zung-1:~/docker/caddy$ curl -v https://zung102-olympic.nord
*   Trying 100.122.127.103:443...
* connect to 100.122.127.103 port 443 failed: Connection refused
* Failed to connect to zung102-olympic.nord port 443 after 0 ms: Connection refused
* Closing connection 0
curl: (7) Failed to connect to zung102-olympic.nord port 443 after 0 ms: Connection refused

Thank you very much for your great help!

Keep in mind that localhost inside of a container means “this same container” so Caddy would be proxying to itself. Make sure to use the name of the other container you want to connect to, e.g. vaultwarden:80

Okay, but try without removing the Server header. It’ll tell us what’s causing the redirect loop. And what’s in Caddy’s logs with debug enabled?

Make sure your upstream isn’t configured to perform HTTP->HTTPS redirects, or at least is configured to recognize that Caddy is passing X-Forwarded-Proto: https which should tell it not to.

1 Like

reverse-proxy localhost:80 was what I found on internet for allowing HTTPS access to local domain name. An example was here https://caddy.community/t/making-a-https-local-domain-for-local-service/18051.

I also have tried to specify reverse-proxy vaultwarden:80, The results from curl appeared better …

curl -v https://zung102-olympic.nord
*   Trying 100.122.127.103:443...
* Connected to zung102-olympic.nord (100.122.127.103) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: [NONE]
*  start date: Jun 23 19:30:10 2023 GMT
*  expire date: Jun 24 07:30:10 2023 GMT
*  subjectAltName: host "zung102-olympic.nord" matched cert's "zung102-olympic.nord"
*  issuer: CN=Caddy Local Authority - ECC Intermediate
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x56053c448560)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: zung102-olympic.nord
> user-agent: curl/7.81.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200 
< alt-svc: h3=":443"; ma=2592000
< cache-control: public, max-age=600
< content-security-policy: default-src 'self'; base-uri 'self'; form-action 'self'; object-src 'self' blob:; script-src 'self' 'wasm-unsafe-eval'; style-src 'self' 'unsafe-inline'; child-src 'self' https://*.duosecurity.com https://*.duofederal.com; frame-src 'self' https://*.duosecurity.com https://*.duofederal.com; frame-ancestors 'self' chrome-extension://nngceckbapebfimnlniiiahkandclblb chrome-extension://jbkfoedolllekgbhcbcoahefnbanhhlh moz-extension://* ; img-src 'self' data: https://haveibeenpwned.com https://www.gravatar.com ; connect-src 'self' https://api.pwnedpasswords.com https://api.2fa.directory https://app.simplelogin.io/api/ https://app.anonaddy.com/api/ https://api.fastmail.com/ ;
< content-type: text/html; charset=utf-8
< date: Fri, 23 Jun 2023 22:20:04 GMT
< expires: Fri, 23 Jun 2023 22:30:04 GMT
< permissions-policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()
< referrer-policy: same-origin
< server: Caddy
< server: Rocket
< strict-transport-security: max-age=31536000;
< x-content-type-options: nosniff
< x-frame-options: DENY
< x-frame-options: SAMEORIGIN
< x-robots-tag: none
< x-xss-protection: 1; mode=block
< x-xss-protection: 0
< content-length: 1240
< 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
<!doctype html><html class="theme_light"><head><meta charset="utf-8"/><meta name="viewport" content="width=1010"/><meta name="theme-color" content="#175DDC"/><title page-title>Vaultwarden Web Vault</title><link rel="apple-touch-icon" sizes="180x180" href="images/apple-touch-icon.png"/><link rel="icon" type="image/png" sizes="32x32" href="images/favicon-32x32.png"/><link rel="icon" type="image/png" sizes="16x16" href="images/favicon-16x16.png"/><link rel="mask-icon" href="images/safari-pinned-tab.svg" color="#175DDC"/><link rel="manifest" href="ca8f66ed7fccfcd0809f.json"/><script defer="defer" src="theme_head.5f24ba8d7aa944e6f52b.js"></script><link href="app/main.c107f7b9354b6317446a.css" rel="stylesheet"></head><body class="layout_frontend"><app-root><div class="mt-5 d-flex justify-content-center"><div><img class="mb-4 logo logo-themed" alt="Bitwarden"/><p class="text-center"><i class="bwi bwi-spinner bwi-spin bwi-2x text-muted" title="Loading" aria-hidden="true"></i></p></div></div></app-root><script defer="* Connection #0 to host zung102-olympic.nord left intact
defer" src="app/polyfills.428c25638840333a09ee.js"></script><script defer="defer" src="app/vendor.776201439bfdefee32dc.js"></script><script defer="defer" src="app/main.3a27378a743dd4ad9f70.js"

but from Microsoft Edge browser from another local PC it still said the site was not secure…is that normal or as expected

https://zung102-olympic.nord/#/login
prefix https was crossed out
Your connection isn't private
Attackers might be trying to steal your information from zung102-olympic.nord (for example, passwords, messages, or credit cards).
NET::ERR_CERT_AUTHORITY_INVALID

Yep that looks good :+1:

You need to install Caddy’s root CA cert on every machine that will be making requests to your server. You can use the same command I linked earlier to copy it out of your container, then copy it to your other machines and install it there.

You mean the root.crt file? if so where do I copy it to in a Windows PC?

Yes, that file. Use Google to find instructions for installing your own root certificate.

Thank you again for all the help you provided. I have found some instructions in the internet to import the root CA into Windows. It worked now.

2 Likes

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