Http.proxy to backend signed by own CA

[lukenowak (łukasz Nowak)]

Hello guys,

First - again thanks for nice software and you work.

Now, let’s get to the business.

I have a situation, that I am using http.proxy to serve some content with Caddy as a frontend. In order to know that I am talking with correct backend, I want to use https:// endpoint. As my backend’s certificates are signed by our own CA, I am currently forced to use insecure_skip_verify. This results, that I can’t verify my backends.

In the Feature request: self-signed certificates for upstreams · Issue #1550 · caddyserver/caddy · GitHub @mattme said:

What about just adding your CA to the system’s trust store?

Ok. On system level I shall add something to where package ca-certificates work. But I am compiling my own go and compiling caddy by myself. (Now it maybe becomes go question, but)…

Can I convince go during compilation (or runtime for each caddy running process?!) to point it to different CA store and then put my CA certificates there? I did a (too) short research about it (googled for golang ca trust store) and found How To Trust Extra CA Certs In Your Go App · for func() sake { }, but this is development-level thing, even if they propose similar approach, it is not specific enough to help me.

Do anyone knows nice hack around it?

I am eager to work/help on Feature request: self-signed certificates for upstreams · Issue #1550 · caddyserver/caddy · GitHub, which I hope would result with http.proxy parameter ca_store or something, but such hack would buy my time.

Thanks,
Łukasz

[lukenowak (łukasz Nowak)]

Hi,

Well, I think I just found a hope. According to x509 package - crypto/x509 - Go Packages I can:

On UNIX systems the environment variables SSL_CERT_FILE and SSL_CERT_DIR can be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively.

I am giving it a try in my crazy environment, I’ll let you know.

Łukasz

[Whitestrake (Matthew Fay)]

That could be a neat trick.

But yeah, I’ve never seen anyone bother with a solution other than simply copying the root cert to /usr/local/share/ca-certificates and running sudo update-ca-certificates.

[lukenowak (łukasz Nowak)]

Hello,

@Whitestrake

That could be a neat trick.

Yes, but I realised, that this is configuration for the whole caddy process.

What I need for “shared hosting” is capability to use different set of CAs for each proxy I serve with one process.

So the solution from How To Trust Extra CA Certs In Your Go App · for func() sake { } :

3. Replace the RootCAs in our client tls.Config{} with the self-signed CA cert

is what I really need. It will need to work on mentioned bug.

I’ll try to help on this issue as soon as possible.

Regards,
Łukasz

[lukenowak (łukasz Nowak)]

Hello,

@lukenowak

On UNIX systems the environment variables SSL_CERT_FILE and SSL_CERT_DIR can be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively.

I am giving it a try in my crazy environment, I’ll let you know.

I just checked and running caddy with environment variable SSL_CERT_FILE which points to CA certificate works for proxy validation.

Regards,
Łukasz