Invalid TLS certificates when running locally on Windows with local certs

1. Caddy version (caddy version):

v2.5.1 h1:bAWwslD1jNeCzDa+jDCNwb8M3UJ2tPa8UZFFzPVmGKs=

2. How I run Caddy:

Locally

a. System environment:

Windows 10 native, from Powershell 7.2.4 inside Windows Terminal 1.12.10982.0

b. Command:

caddy.exe run --watch --adapter caddyfile --config Caddyfile

c. Service/unit/compose file:

n/a

d. My complete Caddyfile or JSON config:

{
    log {
        output file C:\Users\Pierstoval\.rymfony\{long uuid}\log\http.server.log
    }
    local_certs
}

127.0.0.1:8000 {
    root * C:\dev\rymfony\

    encode gzip

    header -Server

    log {
        output file C:\Users\Pierstoval\.rymfony\{long uuid}\log\http.vhost.log
    }

    php_fastcgi 127.0.0.1:60000 {
        env SERVER_SOFTWARE "Rymfony/Caddy"
        index index.php
        resolve_root_symlink
    }

    file_server
}

3. The problem I’m having:

Running an HTTP server that has fastcgi capabilities, file server, local TLS certificates, only for local development.

TLS doesn’t seem to work properly for some reason that I cannot fathom.

To make it work, I have to “ignore TLS errors” (which is possible with Curl, but not all other HTTP clients…)

4. Error messages and/or full log output:

For instance, when running Curl:

$ curl -i https://127.0.0.1:8000
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - La fonction de révocation n’a pas pu vérifier la révocation du certificat.

(sorry error messages are in French)

As said, it works with Curl if I use the -k / --insecure command-line option, since this ignores some TLS errors.

But also when using Symfony HTTPClient:

Symfony\Component\HttpClient\Exception\TransportException: fopen(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

C:\dev\rymfony\vendor\symfony\http-client\Chunk\ErrorChunk.php:62
C:\dev\rymfony\vendor\symfony\http-client\Response\CommonResponseTrait.php:150
C:\dev\rymfony\vendor\symfony\http-client\Response\TransportResponseTrait.php:53
C:\dev\rymfony\tests\ServerTest.php:16

Caused by
Symfony\Component\HttpClient\Exception\TransportException: fopen(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

C:\dev\rymfony\vendor\symfony\http-client\Response\NativeResponse.php:126
C:\dev\rymfony\vendor\symfony\http-client\Response\NativeResponse.php:157
C:\dev\rymfony\vendor\symfony\http-client\Response\NativeResponse.php:340
C:\dev\rymfony\vendor\symfony\http-client\Response\TransportResponseTrait.php:174
C:\dev\rymfony\vendor\symfony\http-client\Response\CommonResponseTrait.php:149
C:\dev\rymfony\vendor\symfony\http-client\Response\TransportResponseTrait.php:53
C:\dev\rymfony\tests\ServerTest.php:16

Here are the HTTP server logs:

{"level":"info","ts":1653254289.6272948,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["//127.0.0.1:2019","//localhost:2019","//[::1]:2019"]}
{"level":"info","ts":1653254289.6272948,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000200770"}
{"level":"info","ts":1653254289.628295,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1653254289.6482499,"logger":"pki.ca.local","msg":"root certificate is already trusted by system","path":"storage:pki/authorities/local/root.crt"}
{"level":"info","ts":1653254289.64874,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:C:\\Users\\Pierstoval\\AppData\\Roaming\\Caddy"}
{"level":"info","ts":1653254289.6487749,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["127.0.0.1"]}
{"level":"warn","ts":1653254289.6499932,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [127.0.0.1]: no OCSP server specified in certificate","identifiers":["127.0.0.1"]}
{"level":"info","ts":1653254289.6501536,"msg":"autosaved config (load with --resume flag)","file":"C:\\Users\\Pierstoval\\AppData\\Roaming\\Caddy\\autosave.json"}
{"level":"info","ts":1653254289.6501536,"logger":"tls","msg":"finished cleaning storage units"}
{"level":"info","ts":1653254289.6501536,"msg":"serving initial configuration"}
{"level":"info","ts":1653254289.6501536,"logger":"watcher","msg":"watching config file for changes","config_file":"C:\\Users\\Pierstoval\\.rymfony\\{long uuid}\\Caddyfile.runtime"}

5. What I already tried:

Caddy is ran by a parent process built with Rust, which is started by PHP via PHPUnit tests.

  • I tried running only the Rust executable, same issue.
  • I tried picking the Caddy command-line instruction to just run Caddy by myself, standalone, and it has the exact same issue.
  • I tried to run caddy untrust and run caddy trust just after, and it made no change on this issue.
  • I tried removing the $HOME\AppData\Roaming\Caddy directory to force Caddy to refresh all the certificates and authority, but no change either.

6. Links to relevant resources:

  • (this should not be necessary, but just in case saying it anyway) Full reproducer is there: GitHub - Orbitale/Rymfony at tests
    To reproduce, you must clone the project on a Windows 10 setup (you will need Rust, PHP and PHP-CGI though).
    Run cargo run serve to start the server, then curl -i https://127.0.0.1:8000 to see the output.
    Note: I don’t know if it is allowed, but I can provide the Caddy binary that I downloaded, as well as a production-compiled version of my project (it’s 39MB, because it contains the Caddy binary).
  • Has to be noted that I’m migrating from Caddy 2.4 to 2.5, and in 2.4 everything was working well, I suppose it might have something to do with the TLS changes in 2.5.0 ?
  • I’m using the caddy_2.5.1_windows_amd64.zip file from the v2.5.1 release.

In the next days, I will try using other versions of Caddy to see what’s going on, but in the meantime I decided to post this issue to see if it was a config problem on my side instead.

It works fine for me on Windows.

Are you sure Caddy’s root cert is in your system’s trust store? In v2.5.1, If you run caddy.exe trust while Caddy is running, it will pull the root cert from the running Caddy instance and attempt to install it to your system’s trust store. When you run this on Windows you should probably get a system prompt asking you Yes/No to add the cert to the trust store or not (I do, anyway).

Some browsers don’t use Windows’ trust store though, and use their own trust stores; so you may need to install the root cert in those browsers’ trust stores manually.

1 Like

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