4

is there a command or UI I can use to test certificates or diagnose why they aren't valid?

A while back Apple changed the requirements for TLS certificates, and announced dates from when those changes would take effect. For example not accepting certificates that last longer than 865 days, requiring extended attributes, etc.

If I use such a certificate, Chrome/Safari don't tell me why it isn't considered invalid if it's an Apple enforced reason such as the ones above.

It'd be great to have a go-to debugging step that'll tell me if a certificate is or isn't good that includes the Apple restrictions.

Clarification: I'm not interested in generating certificates or how to code them. I just want to know how to test if a given certificate is valid on a MacOS system using the terminal or some other OS UI

2
  • Apple changed nothing. Are you referring to this support.apple.com/en-us/HT210176 or perhaps support.apple.com/en-us/HT211025
    – bmike
    Mar 5, 2020 at 19:05
  • 1
    Yes, those requirements will invalidate a certificate on modern Apple platforms such as Catalina, but, they still show as valid for OpenSSH. I believe i found the answer with security verify-cert -c I just need to wait a day to accept my own answer Mar 5, 2020 at 19:10

3 Answers 3

5

So it turns out there is an OS level tool, security

For example, I can test if a certificate ca.crt is valid like this:

security verify-cert -c ca.crt

Here's what a valid certificate will look like:

❯ security verify-cert -c ca.crt
...certificate verification successful.

And here's a certificate with a 10 year expiration that violates Apples rules, but is otherwise valid according to OpenSSH:

❯ security verify-cert -c ca.crt
Cert Verify Result: CSSMERR_TP_NOT_TRUSTED
1

There are two possible ways using the CLI to check the validity of certificates:

  1. You have the certificate files somewhere accessible on your harddisk.
  2. You only have them installed, but not accessible on the harddisk.

Number one needs a bit more CLI work, number two can be done online and shows the complete certificate chain.

  1. You have the certificate files somewhere accessible on your harddisk. For checking the certificate file, we need to know in which format they are. Here is an example with a PEM format file:

    openssl x509 -in FILENAME -text

You can also choose the input format with

openssl x509 -inform PEM -in FILENAME -text

(PEM is default) That gives you a quite long text output on each certificate file and you have to validate the issuer, the CN, the expiration date manually by comparing it to the CA or root certificate. The second method will come in more handy:

  1. You only have them installed, but not accessible on the harddisk.

You can use the openssl s_client command to validate the complete chain.

openssl s_client -connect YOURSERVER:SSLPORT

You will immediately see the certificate AND the installed root chain and openssl is also telling you expiration dates and so on. Here is an example from my personal website:

openssl s_client -connect FQDN-DELETED:443
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = FQDN-DELETED
verify return:1
---
Certificate chain
 0 s:/CN=FQDN-DELETED
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
...
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGUzCCBTugAwIBAgISA+Y4i63Ury6g85b3DghU9muyMA0GCSqGSIb3DQEBCwUA
...
-----END CERTIFICATE-----
subject=/CN=FQDN-DELETED
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3742 bytes and written 322 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
...

There is much more output - just have a look. Send me back questions, if you have.

1
  • See I went down this avenue in the past, and this is great for a general certificate validation issue, but, it doesn't catch stuff like self signed root certificates that fail Apples 825 day limit, or that they have to have certain extended key attributes for Apple to consider them valid Mar 5, 2020 at 18:55
0

Apple has announced some changes for root certificates coming after September 1, 2020.

TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days.

This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS

3
  • The notes there are pretty good, we’re still digesting what this means to us as we make new plans, set up MDM and secure our internal and external servers with certificates. @TomJNowell Apple is documenting things way early now, so that is most welcome.
    – bmike
    Mar 5, 2020 at 19:12
  • What I do not understand in that context is, that Tom J Nowells' problem is related to selfsigned root CA and deriving certificates, when I read into the Apple support article posted: "This change will not affect certificates issued from user-added or administrator-added Root CAs." Mar 6, 2020 at 7:31
  • @MartinAllert that's the linked change, there are other changes I'm having to deal with that do impact self signed certificates. I'm glad this one won't impact me but I'm accounting for it nonetheless Mar 9, 2020 at 13:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .