On 20/12/18 1:13 am, Meridoff wrote:
> Hello, when proxying https traffic squid needs self-signed cert.
No, Squid needs a certificate with properties compatible with the
particular "proxying https" which your proxy is configured to do.
Some of those uses require *a CA* certificate and key. Self-signed is
the simplest type of CA certificate - anybody can create and use one for
whatever they want.
There are other types of CA certificate and any of them are are also
usable in the situations where Squid simply needs a CA cert.
> But what if I use not self-signed cert ?
Depends on what type of certificate properties it *does* have.
> I need to use cert of my
> company which is not self-signed.
Is it a CA certificate? probably not.
Do you actually need a CA for the feature(s) you are trying to use?
probably yes, maybe no.
Please provide details of the config you are trying to setup so we can
answer more accurately. Right now anybody saying yes, no or giving
specific advice will have to be guessing about what you mean.
> Is it possible ? May be I can use
> capath= option for this..
No. The capath= option is for loading *multiple* CA certificates in
OpenSSL. It does not change the type of certificates loaded.
> Now squid complains: FATAL: No valid signing SSL certificate configured
> for HTTPS_port 192.168.1.1:3128 <http://192.168.1.1:3128>
That message from Squid simply says the cert you are loading is not
meeting the minimum requirements for the features you have configured in
Yes that typically means one of the SSL-Bump features is being used and
the cert is not a CA. But there are also other situations that message
comes up, so please supply details about what you are actually trying to do.
On 20/12/18 4:32 am, Meridoff wrote:
> 1) I just try to intercept https traffic. I use https_port ...
> cert=cert.pem capath=/dir . So squid can generate sertificates based on
> file.cert as Root CA.
> So, my file.cert is combined from cert and key files. And it is not
Please change your focus away from the "self-signed" term. As I wrote
earlier it is just a way of saying "Root CA".
The relevant thing is the "CA" part. What is special about CA is that
those certificates can be used to sign other certificates.
Or in other words: CA cert are "signing SSL certificate".
> Checked by openssl:
> openssl verify cert.pem
> cert.pem: CN = *.xxx.com <http://xxx.com>
> error 20 at 0 depth lookup:unable to get local issuer certificate
> And squid complains too: FATAL: No valid signing SSL certificate configured
These are very different messages.
OpenSSL is complaining that the PEM file contains a certificate which
cannot be validated by any CA it trusts.
Squid is complaining that the PEM file does not contain a CA cert + CA
key it can use for signing when generating leaf certificates.
> I think squid want to know who signed this cert - all cert chain to root
> cert. From where squid sholud know where to get all intermidiate CA
> certs for this cert.pem file ?
You have this slightly backwards. The PEM file is where Squid gets the
The PEM file should contain the CA cert + CA key Squid will be using to
generate leaf certs, plus any extra CA chain up to some CA the clients
> 2) In capath dir: is it neccesary to put here files in hash-format (as
> "man verify" for -CApath says): I mean for example 1234abcde.0 PEM-file
> in this dir.
Skip this. Like I said earlier that option is about other things not
relevant to your problem.
Your problem is that you are trying to use a leaf certificate for HTTPS
interception. You need a CA certificate.
The PEM file can contain:
* an intermediary CA cert, or
* a root CA cert (aka self-signed cert), or
* a chain of intermediary CA certs, or
* a chain of intermediary CA certs and their root CA cert.
Notice the constant detail in all those: "CA cert".