On Fri, Dec 08, 2023 at 10:04:25PM +0000, Philipp Benner wrote: > Dear all, > > > I would like to use relayd as an outbound https proxy, so I configured it > like shown in the last section of the relayd.conf(5) manpage. > > This works fine for e.g. wikipedia.org. The certificate issued by my relay is > nearly the same as the original, except oft he issuer of course. > > But when I try to visit e.g. heise.de, at least all images refuse to load. > After some research I found out the following. > > When visiting the site directly without proxy, I can see that the images are > loaded from https://heise.cloudimg.io. If I open an image in a new browser, I > can also see that the certificates applicant is 2e26bae.cloudimg.io, > alternative applicants are heise-aws.cloudimg.io and heise.cloudimg.io > > Now if I use the relayd proxy and try to open an image in a seperate browser, > the url is the same https://heise.cloudimg.io/... but the certificates is > different. Its applicant now is a.248.e.akamai.net and alternatively > *.akamaized.net and some other *.akamai… > > So the self-issued certificate has completely other applicants than the > original and of course doesn‘t match the actual server name and I get the > error ERR_CERT_COMMON_NAME_INVALID > > > Can anybody help or give advice?
Don't do it. This "TLS inspection" mode is broken and it is close to impossible to fix it. The way the MITM cert is built is not smart enough and does not consider many special cases like SAN certs and OCSP. It works for simple things but does not work as a generic SSL interceptor. -- :wq Claudio
