I just setup a load balancer with HAProxy 1.5.2, and the HTTPS frontend work incorrectly.
I use curl to make an request to my server as follow:
curl https://haproxy.example.com
The output as follows:
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://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.
The following are the configuration:
frontend https-in
bind *:443 ssl crt /var/crt/mycrt.pem ca-file /var/crt/myca.crt
reqadd X-Forwarded-Proto:\ https
default_backend https-in-443
The /var/crt/myca.crt are the CA bundle file.
Anybody can help on this issue? thanks a lot.
Finally, i fixed this issue
Just added "verify optional" to the end of bind *:443 ssl crt /var/crt/mycrt.pem ca-file /var/crt/myca.txt as follow
Reference: HAProxy: client side ssl certificates
Related
When I use "curl -v https://hostname/resource.xml" I get the following error:
About to connect() to hostname.com port 443 (#0)
Trying x.x.x.x... connected
Connected to hostname.com (x.x.x.x) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
Peer's certificate issuer is not recognized: 'CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US'
NSS error -8179
Closing connection #0
Peer certificate cannot be authenticated with known CA certificates
curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html
However, when I try: "curl -v https://google.com/"
everything works just fine!
The certificates that validate the websites are located in /etc/ssl/certs
I can assume that this is an issue with SSL certificates and validation because when I run the curl command with -k it works!
I have tried the following to troubleshoot:
Confirmed that date/time is correct on the server
updated the cacert.pem certificate (source: cURL error 60: SSL certificate: unable to get local issuer certificate)
Confirmed that Apache configuration is correct
Tried adding the SSL certificate (website.crt) to /etc/pki/tls
I am running:
CentOS release 6.10 (Final)
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
PHP 7.1.32 (cli)
Would this be caused due to SSLCertificateChain being incomplete?
Any help here is appreciated!
It appears the issuer of your website certificate is an intermediate certificate CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US but it is not sending the full chain, i.e. it is only sending the website certificate without this intermediate certificate. You have 2 options:
Updated the website configuration to bundle the intermediate certificate with the website certificate (preferred method). Follow the instructions here to update the Apache configuration to use the intermediate certificate.
Basically you have to modify the httpd.conf file of your Apache installation, specifically the Virtual Host settings for your website, and point the SSLCertificateChainFile setting to the PEM (crt) file that contains the intermediate cert (CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US)
You can find the intermediate certificate you are missing on the web, for example here, and save this content to a file (e.g. incommon_rsa.crt). Here is what you need to save in the file:
-----BEGIN CERTIFICATE-----
MIIF+TCCA+GgAwIBAgIQRyDQ+oVGGn4XoWQCkYRjdDANBgkqhkiG9w0BAQwFADCB
iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl
cnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNV
BAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQx
MDA2MDAwMDAwWhcNMjQxMDA1MjM1OTU5WjB2MQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCTUkxEjAQBgNVBAcTCUFubiBBcmJvcjESMBAGA1UEChMJSW50ZXJuZXQyMREw
DwYDVQQLEwhJbkNvbW1vbjEfMB0GA1UEAxMWSW5Db21tb24gUlNBIFNlcnZlciBD
QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJwb8bsvf2MYFVFRVA+e
xU5NEFj6MJsXKZDmMwysE1N8VJG06thum4ltuzM+j9INpun5uukNDBqeso7JcC7v
HgV9lestjaKpTbOc5/MZNrun8XzmCB5hJ0R6lvSoNNviQsil2zfVtefkQnI/tBPP
iwckRR6MkYNGuQmm/BijBgLsNI0yZpUn6uGX6Ns1oytW61fo8BBZ321wDGZq0GTl
qKOYMa0dYtX6kuOaQ80tNfvZnjNbRX3EhigsZhLI2w8ZMA0/6fDqSl5AB8f2IHpT
eIFken5FahZv9JNYyWL7KSd9oX8hzudPR9aKVuDjZvjs3YncJowZaDuNi+L7RyML
fzcCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFFN5v1qqK0rPVIDh2JvAnfKyA2bL
MB0GA1UdDgQWBBQeBaN3j2yW4luHS6a0hqxxAAznODAOBgNVHQ8BAf8EBAMCAYYw
EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUH
AwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgGBmeBDAECAjBQBgNVHR8ESTBHMEWgQ6BB
hj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNh
dGlvbkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNo
dHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5j
cnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI
hvcNAQEMBQADggIBAC0RBjjW29dYaK+qOGcXjeIT16MUJNkGE+vrkS/fT2ctyNMU
11ZlUp5uH5gIjppIG8GLWZqjV5vbhvhZQPwZsHURKsISNrqOcooGTie3jVgU0W+0
+Wj8mN2knCVANt69F2YrA394gbGAdJ5fOrQmL2pIhDY0jqco74fzYefbZ/VS29fR
5jBxu4uj1P+5ZImem4Gbj1e4ZEzVBhmO55GFfBjRidj26h1oFBHZ7heDH1Bjzw72
hipu47Gkyfr2NEx3KoCGMLCj3Btx7ASn5Ji8FoU+hCazwOU1VX55mKPU1I2250Lo
RCASN18JyfsD5PVldJbtyrmz9gn/TKbRXTr80U2q5JhyvjhLf4lOJo/UzL5WCXED
Smyj4jWG3R7Z8TED9xNNCxGBMXnMete+3PvzdhssvbORDwBZByogQ9xL2LUZFI/i
eoQp0UM/L8zfP527vWjEzuDN5xwxMnhi+vCToh7J159o5ah29mP+aJnvujbXEnGa
nrNxHzu+AGOePV8hwrGGG7hOIcPDQwkuYwzN/xT29iLp/cqf9ZhEtkGcQcIImH3b
oJ8ifsCnSbu0GB9L06Yqh7lcyvKDTEADslIaeSEINxhO2Y1fmcYFX/Fqrrp1WnhH
OjplXuXE0OPa0utaKC25Aplgom88L2Z8mEWcyfoB7zKOfD759AN7JKZWCYwk
-----END CERTIFICATE-----
Add the intermediate certificate to the list of system-trusted CA certificates (less-preferred method, intermediate certificates should be sent by clients and not trusted implicitly by adding it to the list of system-trusted CA certs ).
Again, save the intermediate certificate file with the content I provide above and then install it in your list of trusted CA certificates using the CentOS tools for doing this as described here.
I'm trying to setup client certificate authentication using haproxy.
With openssl I have created a CA and an intermediate CA. I want to allow only client certs signed by this intermediate CA.
What should I provide in the ca-file option : intermediate CA cert or should I provide concatenation of cert + key ?
When using cert or cert chain (cat CA + intermediate) I get the following error : ERR_BAD_SSL_CLIENT_AUTH_CERT and the browser doesn't ask me for a cert.
here is the haproxy bind config :
bind *:443 ssl crt /etc/ssl/private ca-file /etc/haproxy/ca-chain.cert.pem verify required crt-ignore-err all
Thanks for your help,
Jonathan
Hi have a problem with SSL and haproxy, i have concatenated the .crt with the private key but if i check SSL state, my site is not trusted and i need install a bundle certificate, i have tried in this way:
bind *:443 ssl crt /etc/ssl/mydomain.com.pem ca-file /etc/ssl/mydomain.com-ca.bundle
But don't work. HA proxy version 1.5.2
OK i resolved, i create a .pem file with (in order): certificate, intermediate and private key. It work's
I am using self signed certificates with Apache mod_ssl module but I am getting
> curl_easy_perform() failed on: https://localhost/auth/example (SSL
> certificate problem: self signed certificate)
Is their a way to make ssl not fail? I know that curl has the option --insecure or -k so is there something similar I can add to http-ssl.conf?
mod_ssl will present whatever certificate it is configured to present. It is a client decision whether to accept the presented certificate or not; there is nothing you can configure in mod_ssl, other than the certificate itself, that will influence client verification.
If you want Curl to accept the server certificate, you can either:
Use --insecure/-k (as you are already aware)
Obtain a certificate signed by a public, trusted certificate authority (CA)
Use a self-signed CA to sign the server certificate, and tell Curl to verify the server certificate using that CA via the --cacert <CA certificate> option.
I've recently obtained a PositiveSSL certificate at Namecheap and installed it on my server. Accessing the site from Firefox works fine, but accessing it from Ruby's net/https library doesn't work: it fails to verify the connection certificate even though I've specified the path to the certificate and I've checked that the file is readable. Curl also fails:
curl --cacert /path/to/cert https://mysite.com/
It simply says something like this:
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://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.
"certificate verify failed" isn't a terribly useful error message. How do I find out what exactly is wrong with my certificate and what to do about it? I find it confusing that it works in the browser but not anywhere else.
It looks like curl requires that the CA certificate file contains ALL certificates in the chain. I've downloaded all of them and combined them into a single file and now both Curl and Ruby are happy.