Curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

[rajeevmassey]

My domain is: cloud.myhandycash.com

I ran this command: curl  -v  -H “Content-Type: application/json” POST  -d ‘{“pkData”:“BM6tlV2SNIjVFj6ys2WQHsvW3MVLYK8Q2tQdIIykGpHYkFAWST6jDGuzrUCrgJx+N5u/V//9fxkPGTvFQHEfdHg=”}’ https://cloud.myhandycash.com/account

It produced this output:* Connected to cloud.myhandycash.com (18.216.182.18) port 443 (#1)

• ALPN, offering h2
• ALPN, offering http/1.1
• successfully set certificate verify locations:
•   CAfile: none
   CApath: /etc/ssl/certs
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.2 (IN), TLS handshake, Certificate (11):
• TLSv1.2 (IN), TLS handshake, Server key exchange (12):
• TLSv1.2 (IN), TLS handshake, Request CERT (13):
• TLSv1.2 (IN), TLS handshake, Server finished (14):
• TLSv1.2 (OUT), TLS handshake, Certificate (11):
• TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
• TLSv1.2 (OUT), TLS change cipher, Client hello (1):
• TLSv1.2 (OUT), TLS handshake, Finished (20):
• TLSv1.2 (IN), TLS alert, Server hello (2):
• error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate
• stopped the pause stream!
• Closing connection 1
  curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

My web server is (include version): is an ec2-instance running multiple docker container and the service is exposed to port 443 with embedded apache tomcat as the we server of each of the containers

The operating system my web server runs on is (include version): ubuntu

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.30.2

[Osiris]

This isn’t an issue with the Let’s Encrypt certificate. Your webserver requires a client certificate. When the client doesn’t provide any, the connection will be closed.

Also, your domain has DNSSEC issues: http://dnsviz.net/d/cloud.myhandycash.com/dnssec/

This can prevent DNSSEC enabled DNS servers to refuse to resolve the hostname(s).

[rajeevmassey]

how to share a client certificate. Kindly let me know the commands to do so. I have all the 4 files when creating the SSL certificate

[Osiris]

I’m not sure what you’re asking.

Do you know what a client authentication certificate is? Did you set up the webserver to request this?

Also, I’m pretty sure this isn’t a Let’s Encrypt issue, but more of a “generic” webserver configuration issue.

[rajeevmassey]

I have configured the server to accept for client authentication. And I am using Curl to test the service, so is it possible to bypass or work with a self signed client certificated and also. Is there is any other way to test the service other than curl please let me know.

Please let me know the commands to reach to the solution

[Osiris]

curl can use client certificates. From man curl:

   -E, --cert <certificate[:password]>
          (TLS) Tells curl to use the specified client certificate file when getting a file with HTTPS,  FTPS  or
          another SSL-based protocol. The certificate must be in PKCS#12 format if using Secure Transport, or PEM
          format if using any other engine.  If the optional password isn't specified, it will be queried for  on
          the terminal. Note that this option assumes a "certificate" file that is the private key and the client
          certificate concatenated! See -E, --cert and --key to specify them independently.

          If curl is built against the NSS SSL library then this option can tell curl the nickname  of  the  cer‐
          tificate  to  use  within  the  NSS database defined by the environment variable SSL_DIR (or by default
          /etc/pki/nssdb). If the NSS PEM PKCS#11 module (libnsspem.so)  is  available  then  PEM  files  may  be
          loaded.  If  you  want to use a file from the current directory, please precede it with "./" prefix, in
          order to avoid confusion with a nickname.  If the nickname contains ":", it needs to be preceded by "\"
          so  that  it  is  not  recognized  as password delimiter.  If the nickname contains "\", it needs to be
          escaped as "\\" so that it is not recognized as an escape character.

          (...)

          If this option is used several times, the last one will be used.

          See also --cert-type and --key and --key-type.

[rajeevmassey]

curl --cacert cacert.pem:password -vvv  -H “Content-Type: application/json”  POST  -d ‘{“pkData”:“BM6tlV2SNIjVFj6ys2WQHsvW3MVLYK8Q2tQdIIykGpHYkFAWST6jDGuzrUCrgJx+N5u/V//9fxkPGTvFQHEfdHg=”}’ https://ec2-18-216-182-18.us-east-2.comp
ute.amazonaws.com/account

This command is still not helping

[schoen]

The curl option --cacert is totally different from --cert. @Osiris pointed you to the curl documentation about --cert, not --cacert. If you want to use a client cert with curl, you’ll need to use --cert.

The reason this question is a bit confusing to us is that you apparently set up this web server yourself, so the server’s policy about requiring client certificate authentication was decided by you. If you don’t want the certificate to require client certificate authentication, you could also just configure it not to.

If you want it to require client certificate authentication but you haven’t figured out how to make this work, you should probably look more closely at the documentation for the client and server that you’re using. Every aspect of whether the server requires this kind of authentication or not, and which certificates it considers valid for this purpose or not, is determined by your own server configuration.