0

TL;DR I'm looking for a way to granularly control whether MacOS trusts a certificate for each individual purpose specified in the Basic Constraints (2.5.29.19), Key Usage (2.5.29.15), and Extended Key Usage (2.5.29.37) extensions.


Consider the following (example) certificate:

-----BEGIN CERTIFICATE-----
MIIHQjCCBSqgAwIBAgIUXTOrFr7KK9eWudfZZTJRPI5U9/IwDQYJKoZIhvcNAQEN
BQAwgekxCzAJBgNVBAYTAlhZMRIwEAYDVQQIDAlOZXZlcmxhbmQxGTAXBgNVBAcM
EEltYWdpbmF0aW9udmlsbGUxHzAdBgNVBAoMFkltYWdpbmFyeSBPcmdhbml6YXRp
b24xIjAgBgNVBAsMGVB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUxKjAoBgNVBAMM
IWltYWdpbmFyeW9yZ2FuaXphdGlvbi5leGFtcGxlLmNvbTE6MDgGCSqGSIb3DQEJ
ARYraW1hZ2luYXJ5QGltYWdpbmFyeW9yZ2FuaXphdGlvbi5leGFtcGxlLmNvbTAe
Fw0yMzEyMzAyMTQ2MDRaFw0zMzEyMjcyMTQ2MDRaMIHpMQswCQYDVQQGEwJYWTES
MBAGA1UECAwJTmV2ZXJsYW5kMRkwFwYDVQQHDBBJbWFnaW5hdGlvbnZpbGxlMR8w
HQYDVQQKDBZJbWFnaW5hcnkgT3JnYW5pemF0aW9uMSIwIAYDVQQLDBlQdWJsaWMg
S2V5IEluZnJhc3RydWN0dXJlMSowKAYDVQQDDCFpbWFnaW5hcnlvcmdhbml6YXRp
b24uZXhhbXBsZS5jb20xOjA4BgkqhkiG9w0BCQEWK2ltYWdpbmFyeUBpbWFnaW5h
cnlvcmdhbml6YXRpb24uZXhhbXBsZS5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDH+nD8CO78AY0dHgqQsvgYPXcla2xBwI7/1sVUnPLMTr8l/QOK
y0pcKOwsSH0YKhGSy6IP7iARkjCIhEaAIRmoiMo2NbU6Vj1mcVq4MfVPKsiBTZk4
5G+xMryaFGy7Uobqp7VQmPA72PdqOShsjJbtAd6Jlkj8ZIclF3KM+QO8nLjx/MAY
LpciFv+wPoZykg9eK0loEgPEwOYLOKHDqfNOwhyx9ZqNE5Fi638GbzXtkn5PRP/N
foXMBcx6G95FkW+BeS7OkBdm4JdXjxscQf+MxhKywzwc5/pZtUFxgEUa4cCYVJ3f
3tpubihZbdOiVWW3Q7AIbKsjsLToI8BRYAouYeFtiho9pJl7lUtz/aPxt7D49OqP
sUQVwlVan3xkmWyLV4W/zdxyGwd+XBMUn5L66lTeAYQ4OV0c4K8jPUiSe2/sTRZS
xV2XarShKBYPEnJM0xmGr7L89E96zLLFDUNq6Pn32O08xFopeIUpGbZDdHBwh0WZ
j6vLA2zyDhMVu5fCUFqeQbeDTLrQ5ZC6Oel0hew8x0SZhhv9J+LJnH4SJgjcEROM
sxrikvgZKpsLQlvB+BTWMJuylbrZRKuUNwNYigGmfVLU6x+nCMjqbKyEBmtkeOQn
aKY/xNWOr8azYlvgU7wpxsjZGZdMir2StIm2LVyUg0YwvyDs8H6UVYHhHQIDAQAB
o4HfMIHcMB0GA1UdDgQWBBQdb+QMmYKiMK5KefpVMTNb3H5xnTAfBgNVHSMEGDAW
gBQdb+QMmYKiMK5KefpVMTNb3H5xnTASBgNVHRMBAf8ECDAGAQH/AgECMA4GA1Ud
DwEB/wQEAwIB/jB2BgNVHSUBAf8EbDBqBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsG
AQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwgGCCsGAQUFBwMJBggrBgEFBQcDEQYK
KwYBBAGCNwIBFgYKKwYBBAGCNwoDAQYKKwYBBAGCNwoDBDANBgkqhkiG9w0BAQ0F
AAOCAgEAkNJ+cNETwLyPsk5NzEY2awWAByD6FATDlwweukbPJbxrCWt1ZWZaJot+
cxuRbmu2Ef+hBqvdq6nACPIiGS3H5ojG/bikZ0ez637XM58p8O5zVkukTF0e8QBA
txNTgXDMgHcdPso8oI3+1KqOynBj07SYKrVxacnuHOdh3srcd3XVg5b149YY+8GE
jepVaGfxN2qO5BHDgFwuBvBPyO1CrNmqT7vBGpYwpCsu8MslgpzCUPmiP3cP46n9
AZzJ7GMRTvoKEJ8q4544q4oIR9aCS/bsN9qu0go1i+J01t+XxTvGAyCnRmh6DLI2
bMTQYqd+bInEVtEvTN2w5B6hFRgLNQOjS15NHkZahSOQiesJsr8f1jbI7ucxA6dq
ZUaofBNOOASx69hMXwjPwR0Gd0mIrFxJtkBGI8CeysATj686qArgtSmt7RB3aTTm
30JE7y0FjTe47+UI+8NWGxfwk2Qo2eHo9n+sncO+9F3Zd6obiChcaK5YXPSHfEVo
4CVIB2BMy4aspDiMkPza9d5vs3KW0AVPHgaN7pnvDs99kzjbYbG6vJMu+ssEOMa0
S8fzYglgwo6I2lcKNXCmGG1UoXUYmv7LljLW+u6NCiC9MBvyix8WYf1M4yCf45iE
3Xrmsc/Yx+ua9hDaY5sUvkdeVOFBWGDtbHCjOxnwtguLlDWvBDA=
-----END CERTIFICATE-----

I would like to trust this certificate for the following purposes:

  • Securing connections to imaginaryorganization.example.com
  • Signing emails from and encrypting emails to [email protected]
  • Signing code

but not for the following purposes:

  • Acting as a certificate authority (despite the fact that the certificate claims in the Basic Constraints extension that it is a certificate authority)
  • Time stamping
  • OCSP signing
  • CRL signing
  • Certificate signing

How can I accomplish this? Keychain Access only gives a very limited set of options for certificate trust settings.

Bonus questions

  • Is there a way to trust a CA for signing S/MIME certificates but not for authenticating client-server connections (or vice versa)?
  • Is there a way to trust a CA for signing certificates only belonging to a certain domain or subdomain, or to a list of domains or subdomains?

1 Answer 1

1

Granular Policies

How can I accomplish this?

Keychain Access reflects what is possible with macOS. A certificate has a single associated trust policy, and the policy defines what is permitted:

macOS uses a number of trust policies to determine whether a certificate is trusted. You can choose a different policy for each certificate, providing a greater amount of control over how certificates are evaluated.

You can read the Policy developer documentation underpinning the macOS Security frameworks. The default policies in macOS are defined as:

macOS Trust Policies

Policy Description
Use System Defaults or no value specified Use the default setting for the certificate.
Always Trust Trust the author and always allow access to the server or app.
Never Trust Don’t trust the author and don’t allow access to the server or app.
Secure Sockets Layer (SSL) The name in a server’s certificate must match its DNS host name to successfully establish a connection. The host name check is not performed for SSL client certificates. If there is an extended key usage field, it must contain an appropriate value.
Secure Mail (S/MIME) Email uses S/MIME to securely sign and encrypt messages. The user’s email address must be listed in the certificate, and key usage fields must be included.
Extensible Authentication Protocol (EAP) When you connect to a network that requires 802.1X authentication, the name in the server’s certificate must match its DNS host name. Host names for client certificates are not checked. If an extended key usage field is present, it must contain an appropriate value.
IP Security (IPSec) When certificates are used to secure IP communications (for example, in establishing a VPN connection), the name in the server’s certificate must match its DNS host name. Host names for client certificates are not checked. If an extended key usage field is present, it must contain an appropriate value.
Code Signing The certificate must contain key usage settings that explicitly permit it to sign code.
Time Stamping This policy determines whether the certificate can be used to create a trusted time stamp, which verifies that a digital signature occurred at a particular time.
X.509 Basic Policy This policy determines the validity of the certificate against basic requirements such as being issued from a valid certificate authority, but without concern for the purpose or the allowed key usage.

For the situation you describe, a custom policy would need to be created.

An application can create custom policies for evaluating certificates, but an API for installing custom policies system wide is not obvious. Nor is there any mention of custom policies in the security command line tool.

This may be possible within a managed environment but, again, there is no obvious documentation.

This all means a more granular approach is not trivially possible with the security framework offered by macOS.

Third party software is not required to use the built-in security frameworks and could offer the granular approach you seek.

Minimal Certificates

Is there a way to trust a CA for signing S/MIME certificates but not for authenticating client-server connections (or vice versa)?

Certificates should be issued with the minimal capabilities required to perform their role. Issue certificates as needed for each sub-role.

The example certificate is too broad:

Extension=Key Usage ( 2.5.29.15 )

  • Critical=YES
  • Usage=
    • Digital Signature
    • Non-Repudiation
    • Key Encipherment
    • Data Encipherment
    • Key Agreement
    • Key Cert Sign
    • CRL Sign

Extension=Basic Constraints ( 2.5.29.19 )

  • Critical=YES
  • Certificate Authority=YES
  • Path Length Constraint=2

Extension=Extended Key Usage ( 2.5.29.37 )

  • Critical=YES
  • Purpose #1=Server Authentication ( 1.3.6.1.5.5.7.3.1 )
  • Purpose #2=Client Authentication ( 1.3.6.1.5.5.7.3.2 )
  • Purpose #3=Code Signing ( 1.3.6.1.5.5.7.3.3 )
  • Purpose #4=Email Protection ( 1.3.6.1.5.5.7.3.4 )
  • Purpose #5=Time Stamping ( 1.3.6.1.5.5.7.3.8 )
  • Purpose #6=OCSP Signing ( 1.3.6.1.5.5.7.3.9 )
  • Purpose #7=( 1.3.6.1.5.5.7.3.17 )
  • Purpose #8=Commercial Code Signing ( 1.3.6.1.4.1.311.2.1.22 )
  • Purpose #9=Certificate Trust List Signing ( 1.3.6.1.4.1.311.10.3.1 )
  • Purpose #10=Encrypted File Systems ( 1.3.6.1.4.1.311.10.3.4 )

Certification Authority Authorization

Is there a way to trust a CA for signing certificates only belonging to a certain domain or subdomain, or to a list of domains or subdomains?

A Certificate Authority (CA) can sign any certificate. The evaluating software is responsible for additional checks.

Publish a DNS Certification Authority Authorization entry for the domains:

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

You must log in to answer this question.

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