0

I have multiple Intel NUCs out in the field that I use for displaying digital signage. Out of the thousands I have in the field, a couple complain with this error:

SSL certificate problem: self signed certificate in certificate chain. 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.

I've confirmed that the cert is not expired, and the domain name matches

These units are running on Debian 7

Could the network they are on cause this issue with some sort of firewall setting?

Andrew
  • 3,545
  • 4
  • 31
  • 37
  • There might be SSL interception going on done by some firewall which will result in the client getting a different certificate than the one you server. Please check what certificates you actually get at the client to further debug the problem. – Steffen Ullrich Feb 27 '19 at 04:37

1 Answers1

-1

When you visit the website what certificate is shown in the web browser? In your curl bundle is that the same certificate which is supposed to be used for SSL encryption? I'd guess no. CA will sign your cert.pem so that web browsers will show your green lock thereby authenticating your website. You most likely have an issue on the back end with the configuration of your curl bundle. You need to make sure that your server is using the CA cert not a self signed certificate like ssl-cert-snakeoil.pem for example.

Essentially your website should be using a static IPv4 address. As far as a network firewall stopping an SSL handshake from happening that may be possible, I have seen it happen on specific ports for example port 22 for ssh connections may be blocked at the network gateway for inbound traffic on a client side computer attempting a connection to a server. The SYN/ACK https://tools.ietf.org/rfc/rfc793.txt TCP handshake may time out in that type of network fire wall situation. However since you are getting an explicit response from your server about a self signed cert a firewall issue does not seem to be the problem.

Nelson Canino
  • 45
  • 7
  • Certificate errors are unrelated to static IPv4, SYN/ACK or whatever at the network layer. If the connection is blocked it will not result in the error described by the OP but more in things like connection reset or connection timeout or no route to host. And while you kind of acknowledge that all of this has nothing to do with the problem of the OP it is unclear why you add it to the answer in the first place. And no, the response from the server is not about a self signed certificate. This error is instead generated on the client based on the certificates received from the server. – Steffen Ullrich Feb 27 '19 at 04:41