If you operate a Netgear switch in an environment that is subject to compliance requirements such as PCI or HIPAA, you are probably doing vulnerability scans, and the HTTP management interface of your switches will generate medium vulnerabilities (at least from Nessus):

SSL Self-Signed CertificateSSL Certificate Cannot Be Trusted* SSL Certificate Expiry

It IS possible to use signed certificates to secure the HTTPS interface on a Netgear switch, but the process to do so is insanely obscure. I do not know how someone had time to figure this out! Apparently, even Netgear tech support didn’t have any idea.

curl, or an application that uses libcurl, may have a problem with an SSL certificate that works fine when using a web browser to access the same URL. Typical error output from curl looks like this:

$ curl -v https://my-subdomain.mysecuresite.com

 Trying xxx.xxx.xxx.xxx:443…
 TCP_NODELAY set
 Connected to my-subdomain.mysecuresite.com (xxx.xxx.xxx.xxx) port 443 (#0)
 ALPN, offering h2
 ALPN, offering http/1.1
 successfully set certificate verify locations:
 CAfile: /etc/ssl/certs/ca-certificates.crt
 CApath: none
 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 (OUT), TLS alert, unknown CA (560):
 SSL certificate problem: unable to get local issuer certificate
 Closing connection 0
 curl: (60) SSL certificate problem: unable to get local issuer certificate
 More details here: https://curl.haxx.se/docs/sslcerts.html 
 curl failed to verify the legitimacy of the server and therefore could not
 establish a secure connection to it. To learn more about this situation and
 how to fix it, please visit the web page mentioned above.

Troubleshooting Strategy

1. A good starting point for any SSL error on a public-facing URL is to analyze the URL at SSL Labs.
2. Does the error happen for all certificates issued by a specific Certificate Authority (CA)? If so, the system running curl may need to have a root certificate for that CA added or updated in its certificate repository. That’s a relatively rare problem, but might occur if the system running curl is very old. There’s a comprehensive thread about this issue on Stack Overflow.
3. If the error only happens for one specific site, it’s likely that the site is missing an intermediate certificate. The command to diagnose this issue is also found in that Stack Overflow thread:

openssl s_client -connect myhost.com:443 -servername myhost.com -showcerts

The output should show a series of certificates, starting with the site certificate, and ending with the root certificate for the Certification Authority. If this chain only shows the site certificate, that’s the problem.

openssl is the standard open-source, command-line tool for manipulating SSL/TLS certificates on Linux, MacOS, and other UNIX-like systems. I recently ran into an interesting problem using openssl to convert a private key obtained from GoDaddy. Someone else used GoDaddy’s “wizard” interface to generate a certificate signing request (CSR) and private key, and saved the files on their Windows workstation. They purchased an SSL cert from GoDaddy, and shared all the files with me for installation on servers. GoDaddy saved the private key in the newer PKCS #8 format (pkcs8), and one system required the key in the older PKCS #1 (pkcs1) format. It’s easy to tell the difference.

Creating Kubernetes secrets isn’t intuitive the first time you do it. A common reason to use a secret is to add a SSL/TLS certificate to a cluster. Kubernetes provides two ways to add a secret: directly on the command line, and from a YAML source file. First, let’s generate a test certificate to work with and select our cluster.

Prerequisites

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=foo.bar.com"

This command produces two files: tls.key and tls.cert. In production, you’d generate a key file and use it to obtain a certificate from a certificate authority.