curl with ssl always uses the local cert-file instead of the one for the remote server
Added by Urs Brauchli 4 months ago
I have bitnami redmine installed and am trying to connect to a remote server using curl using the built in terminal.
But it seems instead of using the remote server's certificate, it always loads some local cert file leading to an error no alternative subject name matches target host name xxx.
When I'm issuing this: openssl s_client -connect www.google.com:443 | openssl x509 -text -noout
I'm getting the certificate (letsencrypt) of my redmine-host as well.
The (partial) output of the openssl-command looks like this:
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = my.localserver.com verify return:1 Certificate: …
So the CN doesn't use google.com, but again the name of my redmine server.
When I look at the /etc/ssl/certs/ca-certificates.crt file, it seems that there are quite a lot in there. Alas, it always seems to select the cert for the local redmine host.
The problem with this is, that we are using the invoice module and have the logo that should be printed on the invoices (as well as a QR-Code for the ESR) are hosted on external servers. But because of the SSL problem, we get an error (server not found) in the invoice module when we try to create a PDF from within the module.
Any ideas what I'm doing wrong?
Replies (2)
RE: curl with ssl always uses the local cert-file instead of the one for the remote server
-
Added by David redminePRO 4 months ago
It looks like your server is routing external HTTPS request to internal HTTPS port. This needs to be checked with a Linx admin.
If you are looking for a fully managed redmine solution, please reach out to me
--
David https://redminepro.com
RE: curl with ssl always uses the local cert-file instead of the one for the remote server
-
Added by Urs Brauchli 4 months ago
We are running a self hosted version of redmine on an internal machine in our network. Thanks for the offer, though.
But: I don't understand the routing problem. Why is this bad, when the external request is routed to the internal https-port? Do they need to be both 443? right now, the internal port is 8443, routed by our fritzbox.