A TLS certificate binds a server key to a site name; openssl reads its fields, checks the chain and issues a new one.
openssl x509 -in site.pem -noout -subject -issuer -dates
openssl x509 -in site.pem -noout -ext subjectAltName
names
openssl x509 -in site.pem -noout -checkend 2592000
30 days?
openssl s_client -connect site.lab.test:443 -servername site.lab.test \
-showcerts </dev/null 2>/dev/null | grep -E '^ *[0-9]+ s:|^ +i:'
openssl verify -CAfile ca.pem -untrusted int.pem site.pem
curl --cacert ca.pem https://site.lab.test/
your own CA
sudo update-ca-certificates
trust the CA
TLS encrypts a connection and, before the first byte of http, lets the client check that the server is who it claims to be. For that the server presents a certificate: a public key, site names and a validity period, vouched for by the signature of a certificate authority. The matching private key stays on the server only.
subject is who it was issued to, issuer who signed it,
notBefore/notAfter the validity period, SAN the
names the certificate is valid for.
| Check | What it compares | curl error |
|---|---|---|
| trust | the signature chain reaches a CA in the store | unable to get local issuer certificate |
| name | the name from the URL is in SAN | no alternative certificate subject name matches |
| date | now is between notBefore and notAfter | certificate has expired |
If any fails, curl exits with code 60 and a browser shows an error page.
curl -k turns all three off: the connection is encrypted, but nobody knows
with whom.
A site certificate is usually signed not by a root but by an
intermediate CA, which the root signed. The root is
signed by itself (subject = issuer) and is
trusted because it sits in the client's trust store. On
Ubuntu that is /etc/ssl/certs; update-ca-certificates adds your own root,
and curl --cacert ca.pem does it for one request.
The client knows only roots. The server sends the intermediate along with the
site certificate — that is the chain. If the server
sends only the site certificate, the client cannot reach the root and reports
unable to get local issuer certificate, even though it has the root.
PEM files are text between -----BEGIN …----- and -----END …----- lines,
base64 inside. The first line tells what the file holds:
| First line | What it is |
|---|---|
-----BEGIN PRIVATE KEY----- |
a private key |
-----BEGIN CERTIFICATE REQUEST----- |
a CSR |
-----BEGIN CERTIFICATE----- |
a certificate |
A certificate is issued from a signing request (CSR): it holds the public key and the requested names. The CA signs the request and returns a certificate. A new request on the old key gives a new certificate without changing the key.
The first certificate in the output is the site certificate. For the whole
chain, look at the s: (subject) and i: (issuer) lines:
Only line 0 — the server does not send the intermediate. -servername
passes the site name at the start of TLS (SNI): nginx with several
sites on 443 picks the certificate by it. Without a name, for example when
connecting to an IP, you get the default server's certificate.
The first command, without the intermediate, says error 20 at 0 depth lookup:
unable to get local issuer certificate. The second says site.pem: OK: the
chain goes from the site through the intermediate to the root.
The order is the site certificate first, the intermediate after it. The root does not go in the file: the client has its own. Using the file in nginx — nginx.
Equal sums mean a pair. If they differ, nginx rejects the config with
key values mismatch.
-copy_extensions copy carries SAN from the request into the certificate.
Without it the certificate has no names: -ext subjectAltName prints
No extensions in certificate, and curl rejects it by name. Put the new
certificate in the file the server uses, then nginx -t and reload.
-checkend N asks whether the certificate expires within N seconds
(2592000 is 30 days): Certificate will expire and code 1, or
Certificate will not expire and code 0. Handy in checks and monitoring.
The file must be named *.crt. The command prints 1 added, 0 removed; done.,
and after that curl and other OpenSSL programs trust this CA's certificates
without --cacert.
A public CA for sites on the internet: certificates last 90 days, and a timer renews them in advance. It needs a DNS name pointing at this server and port 80 reachable from outside. The lab VMs have no outside network, so they use a lab CA.
curl: (60) SSL certificate problem: certificate has expired; openssl
s_client says Verify return code: 10. Check notAfter of the certificate
the server sends (recipe above) and the machine's clock — timedatectl.
Issue a new one, replace the file and reload: nginx keeps the old
certificate in memory.
The client did not reach a trusted root. Two causes:
--cacert or update-ca-certificates;s_client shows a single
0 s: line and Verify return code: 21 (unable to verify the first
certificate). You need a full chain file.curl: (60) SSL: no alternative certificate subject name matches target host
name 'other.lab.test' — the name from the URL is not in SAN. curl answers the
same when you connect by IP. Look at the names: openssl x509 -noout -ext
subjectAltName; if SAN is empty, the certificate was signed without
-copy_extensions.
curl: (60) SSL certificate problem: self-signed certificate; s_client says
code 18. The server sends a certificate it signed itself, and the trust store
does not have it. For your own service, issue a certificate from your own CA
and put the root in the trust store.
curl: (35) … SSL routines::wrong version number — https:// went to a port
that speaks plain HTTP. Check the port and the server's listen … ssl.
The file is replaced but s_client shows the old notAfter: nginx has not
re-read its config. sudo nginx -t && sudo systemctl reload nginx, then check
a second later — nginx.
-k (--insecure) silently accepts a spoofed server, an expired certificate
and a wrong name. A "site answers over HTTPS" check with -k passes even when
users see an error. Use --cacert with the right CA instead.
The key lets anyone pose as the site. Mode 600, owner root, and it never
goes into a repository, an email or a chat. If it leaks, issue a certificate
on a new key.
ssl_certificate, the chain, the redirect to HTTPS.--cacert, -v with the handshake.Found an inaccuracy? Report an error in the article