error from curl: SSL certificate problem: self signed certificate in certificate chain

Not applicable

I am getting below response in the curl. is curl need valid certificate while create vhost., i have already created valid keystore.

curl: (60) SSL certificate problem: self signed certificate in certificate chain More details here: https://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. HTTPS-proxy has similar options --proxy-cacert and --proxy-insecure. curl: (3) <url> malformed curl: (3) <url> malformed curl: (3) <url> malformed curl: (3) <url> malformed

0 1 40.4K
1 REPLY 1

The error from curl is independent of the operation you are attempting - creating a vhost.

The error from curl is a general one. I recommend that you read the article at the suggested URL: https://curl.haxx.se/docs/sslcerts.html It explains how curl works and handles SSL certificates.

"Self signed cert in certificate chain" is a terse message and it may not clearly communicate the issue.

Let's back up and look at a simplified description of how SSL and TLS works:

  • a client connects to a server and says "tell me your identity"
  • The server presents a certificate back to the client. This certificate includes things like "my hostname is example.com" and "this cert is valid from date X to date Y", and "my public key is K". The cert is "digitally signed" by a Certificate Authority (aka CA), using the CA's private key. The signature can be verified with the corresponding public key for the CA.
  • If the client knows the public key of the signing CA, then the client can use that public key to verify the signature on the original server's cert. If the signature is verified, then the client can trust the server's identity (hostname) , and public key, and anything else in the cert. This trust is based on the foundation that the client knows the public key of the signing CA, and knows that public key belongs only to that CA.

An additional layer of complexity comes in when we introduce "certificate chains". You see, there are lots and lots of CAs. And clients cannot directly trust all of them. So what we have settled on, as an industry, is a scheme under which CA certificates (which contain the CA public key) can be signed by other CAs.

  • example.com might present a certificate that is signed by CA1
  • CA1 presents a cert that is signed by CA2
  • CA2 presents a cert signed by RootCA1
  • RootCA1 presents a certificate that is "self signed" - signed by itself, using its own private key, and verifiable using its own public key.

Every TLS client is configured to trust a small number of "Root CAs". These are companies like Entrust, Verisign, and a few others. When verifying the cert for example.com, the client can follow the chain back to the original RootCA1, which it trusts. Since the client trusts RootCA1, it also trusts CA2, and also CA1, and therefore it trusts the cert presented by example.com . This transitive trust is what we refer to when we speak of "certificate chains".

Every client that implements SSL/TLS correctly follows this logic. Read more about it here.

With the error message you provided: ("SSL certificate problem: self signed certificate in certificate chain"), what curl is saying is: I've followed the chain of certificates back to a self-signed certificate, which I do not trust.

-----

The server, in my discussion above it is example.com, is presenting a certificate which is not signed by a trusted CA, or any CA that can be chained back to a trusted CA listed in the client's trust store. curl is rightly saying "I don't trust this cert."

There are three possible solutions:

  • the client, in this case curl, may have an outdated set of trusted root CAs. You need to get the latest set of trusted root CAs to allow curl to trust the self-signed cert. You can get the latest bundle here.
  • If THAT's not the case, then the client has the latest root CAs, and none of those are the root CA for the server;
    • if you really want curl to trust the cert, add the server's self-signed cert to the client's truststore.
    • if you DON'T want curl to trust the cert, then provision a cert for the server that is signed by a trusted party - maybe use LetsEncrypt to do that.

-----

I want to reiterate that the error you see has nothing to do with the operation you're attempting, which I think is creating a vhost in Apigee Edge. The error message is generated during the TLS handshake, which happens before the request to create a vhost gets sent.