OpenIddict upstream

I am in the same situation and would be better if I don’t create a new ticket but please tell me how can you handle this issue to avoid using tls_insecure_skip_verify

I have a similar caddyfile as @Raider . I have a website that requires a SSL cert so I make Caddy to generate the SSL with RSA encoding and transform the key and the cert into a PFX file. I automatically move that file into the config folder of my website so my APP can use the cert to work (openiddict) but when I try to reach to my domain I have the same issue.

tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead

Caddyfile {

This is from the logs

ERR | ts=1707908792.5125453 logger=http.log.error msg=tls: failed to verify certificate: x509: cannot validate certificate for because it doesn't contain any IP SANs request={"remote_ip":"","remote_port":"9349","client_ip":"","proto":"HTTP/3.0","method":"GET","host":"","uri":"/","headers":{"Sec-Fetch-Mode":["navigate"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8"],"Accept-Encoding":["gzip, deflate, br"],"Sec-Fetch-User":["?1"],"Priority":["u=1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0"],"Alt-Used":[""],"Cookie":[],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Site":["same-origin"],"Accept-Language":["es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3"],"Referer":[""]},"tls":{"resumed":true,"version":772,"cipher_suite":4865,"proto":"h3","server_name":""}} duration=0.023410576 status=502 err_id=t6p08shdz err_trace=reverseproxy.statusError (reverseproxy.go:1267)

Is there anything I need to add to caddyfile to issue the correct certificate?

You can use the tls_trusted_ca_certs to tell Caddy to trust the certificates from upstream.

1 Like

Thank you very much for your answer but what parameters should I add to tls_trusted_ca_certs if those certs were issued by Caddy itself with a .crt and .key files? Do i need to convert them to pem?

What do you mean that they were generated by Caddy? Caddy doesn’t have your upstream app’s certificates, unless you’re using Caddy as an ACME server (with the acme_server directive).

What i mean is that I added the reverse_proxy config in the Caddyfile and let Caddy generates the .crt and .key for my domain, then use those files to generate a PFX file for my app and attach that pfx to the OpenIddict configuration. If i set up " tls_insecure_skip_verify" it works but loose all the security related with certs as mentioned here.

without the tls_insecure_skip_verify, i get the following error
" failed to verify certificate: x509: cannot validate certificate for because it doesn't contain any IP SANs "

Those are separate things.

Caddy is using its built ACME client to help you issue a publicly trusted certificate from Let’s Encrypt or ZeroSSL. That’s for incoming connections to your server.

Your proxy is making a new connection to your upstream, and this is unrelated from the original incoming connection.

Are you saying you used Caddy’s server certificate and handed it to your upstream app? That’s definitely wrong. Don’t do that.

Your upstream app (if at all) should be using its own certificate, unrelated to Caddy’s server certificate.

But again, why do you think you must proxy over HTTPS? Just proxy over HTTP.

Apparently OpenIddict has this option to let you turn off HTTPS and use HTTP instead: This server only accepts HTTPS requests. · Issue #864 · openiddict/openiddict-core · GitHub

Thank you very much for the clarification of the difference. It is a requirement for the framework that I am using. It needs a valid SSL cert to make it work.

Is there a way to keep both ssl then? The self-generated in my backend server for my app and the other one for the domain issued by caddyserver and avoid that error message?

What do you mean by “both SSL”?

FYI, it’s been called TLS since 1999, SSL is no longer the right term.

Caddy terminates TLS, meaning that it decrypts the data sent by the client. There’s no reason to re-encrypt it for the upstream app, because the connection between Caddy and your upstream is on a private network.

Just turn off TLS on your upstream app. Since you have Caddy in front of it, there’s no reason for it to expect TLS.

It’s actually more complicated and more effort to maintain and configure TLS. Just turn it off. Much simpler, without the false sense of security.

1 Like

Thank you very much for your time to explain me all this. I learned something new today. I will give it a try and let you know.


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