[GH-ISSUE #415] Starting from Big Sur 11.3 certificate installation requires user interaction

kerem commented

2026-02-25 22:33:00 +03:00

Owner

Originally created by @potatoqualitee on GitHub (Nov 16, 2021).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/415

First, thank you so much for mkcert! I love it and use it often ⭐

It seems that some default behavior may have changed in macOS 11, as mkcert isn't working out of the box on GitHub Actions with macos-latest. (Ah yes, I just read an issue I referenced and it said Starting from Big Sur 11.3 certificate installation requires user interaction, however it can be bypassed by using SecItemAdd method.)

I'm getting the same error as reported in https://github.com/FiloSottile/mkcert/issues/94

And I was advised that I could compile some swift code to solve my issue, similar to what they did in this PR https://github.com/actions/virtual-environments/pull/3311.

swiftc add-certificate.swift
sudo ./add-certificate YourCertName.cer

By the time I was done, however, I wasn't using mkcert anymore. I thought this would be a more appropriate solution to build into mkcert.

Originally created by @potatoqualitee on GitHub (Nov 16, 2021). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/415 First, thank you so much for mkcert! I love it and use it often ⭐ It seems that some default behavior may have changed in macOS 11, as mkcert isn't working out of the box on GitHub Actions with `macos-latest`. (Ah yes, I just read an issue I referenced and it said `Starting from Big Sur 11.3 certificate installation requires user interaction, however it can be bypassed by using SecItemAdd method.`) I'm getting the same error as reported in https://github.com/FiloSottile/mkcert/issues/94 And [I was advised that](https://github.com/actions/virtual-environments/issues/4519) I could compile some swift code to solve my issue, similar to what they did in this PR https://github.com/actions/virtual-environments/pull/3311. ``` swiftc add-certificate.swift sudo ./add-certificate YourCertName.cer ``` By the time I was done, however, I wasn't using `mkcert` anymore. I thought this would be a more appropriate solution to build into mkcert.

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@bilalbayasut commented on GitHub (Nov 22, 2021):

@potatoqualitee where is the add-certificate.swift ?

@bilalbayasut commented on GitHub (Nov 22, 2021): @potatoqualitee where is the add-certificate.swift ?

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@potatoqualitee commented on GitHub (Nov 22, 2021):

add-certificate.swift can be found in GitHub's Runner repo at https://github.com/actions/virtual-environments/blob/main/images/macos/provision/configuration/add-certificate.swift

I got it to compile but then received a "Certificate can't be read" error when I ran it. Since I don't know swift or Apple security well enough, I ran a config override that is acceptable in a CI/CD process but not something I'd want run on my macbook, as it opens the keychain to all users.

@potatoqualitee commented on GitHub (Nov 22, 2021): `add-certificate.swift` can be found in GitHub's Runner repo at https://github.com/actions/virtual-environments/blob/main/images/macos/provision/configuration/add-certificate.swift I got it to compile but then received a "Certificate can't be read" error when I ran it. Since I don't know swift or Apple security well enough, I ran a config override that is acceptable in a CI/CD process but not something I'd want run on my macbook, as it opens the keychain to all users.

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@bilalbayasut commented on GitHub (Nov 23, 2021):

got it working here : https://github.com/FiloSottile/mkcert/issues/412#issuecomment-976429667

@bilalbayasut commented on GitHub (Nov 23, 2021): got it working here : https://github.com/FiloSottile/mkcert/issues/412#issuecomment-976429667

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@FiloSottile commented on GitHub (Apr 26, 2022):

Does the Swift script still work as of macOS 12.3.1? I tried it and the SecTrustSettingsSetTrustSettings invocation still pops up a dialog on my machine. Interestingly enough, the dialog doesn't support Touch ID while the security-driven one does.

By the way, that's a pretty bad script. The return code of SecTrustSettingsSetTrustSettings is not checked, the script will exit silently if SecItemAdd fails, and the certificate label is always Test which I guess made sense in github.com/ibm-bluemix-mobile-services/bms-clientsdk-swift-security@c26988a7f5/Source/mca/internal/certificate/SecurityUtils.swift but not really in a standalone CLI tool.

@FiloSottile commented on GitHub (Apr 26, 2022): Does the Swift script still work as of macOS 12.3.1? I tried it and the `SecTrustSettingsSetTrustSettings` invocation still pops up a dialog on my machine. Interestingly enough, the dialog doesn't support Touch ID while the `security`-driven one does. <img width="291" alt="image" src="https://user-images.githubusercontent.com/1225294/165205687-f89f8d7d-6a36-49a4-8c0c-0c876b1c2eee.png"> By the way, that's a pretty bad script. The return code of `SecTrustSettingsSetTrustSettings` is not checked, the script will exit silently if `SecItemAdd` fails, and the certificate label is always `Test` which I guess made sense in https://github.com/ibm-bluemix-mobile-services/bms-clientsdk-swift-security/blob/c26988a7f5de338c1d9e0d43a64c2b6db33be541/Source/mca/internal/certificate/SecurityUtils.swift but not really in a standalone CLI tool.

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@potatoqualitee commented on GitHub (Apr 26, 2022):

Unfortunately, I have no idea. GitHub would know more. Because my use-case was CI/CD, I just used a command that was way too permissive.

@potatoqualitee commented on GitHub (Apr 26, 2022): Unfortunately, I have no idea. GitHub would know more. Because my use-case was CI/CD, I just used a command that was way too permissive.

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@FiloSottile commented on GitHub (Apr 26, 2022):

Looks like GitHub is indeed still using this script. I tried figuring out why it works on their runners and couldn't reproduce uninteractive behavior. https://github.com/actions/virtual-environments/blob/main/images/macos/provision/configuration/configure-machine.sh

@FiloSottile commented on GitHub (Apr 26, 2022): Looks like GitHub is indeed still using this script. I tried figuring out why it works on their runners and couldn't reproduce uninteractive behavior. https://github.com/actions/virtual-environments/blob/main/images/macos/provision/configuration/configure-machine.sh

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@potatoqualitee commented on GitHub (Apr 27, 2022):

I'll see who I can ping and let you know! Thanks for looking into this

@potatoqualitee commented on GitHub (Apr 27, 2022): I'll see who I can ping and let you know! Thanks for looking into this

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@FiloSottile commented on GitHub (Apr 28, 2022):

Whatever is going on is inconsistent with the SecTrustSettingsSetTrustSettings docs.

When making changes to system-wide trust settings, the user is prompted with an alert panel asking for an administrator’s name and password unless the calling process is running as root, in which case no further authentication is needed.

https://developer.apple.com/documentation/security/1399119-sectrustsettingssettrustsettings

@timsutton found the relevant entry in the Big Sur release notes: https://github.com/FiloSottile/mkcert/issues/322#issuecomment-868822285

macOS Big Sur 11 beta improves system security by requiring an administrator password when a certificate trust settings change is made in the admin trust domain. Running as the root user alone is no longer sufficient to modify certificate trust. User trust domain settings continue to require confirmation by entering the password for the user’s account. This change may affect you if one of the following is true:

You have written scripts which call /usr/bin/security add-trusted-cert -d ... as root.

Your process runs as root and calls the SecTrustSettingsSetTrustSettings function to trust a certificate.

Workflows that add trust settings in the admin trust domain, such as for an enterprise root certificate, may require modification if the user can’t authenticate as an administrator at the time settings are changed. (21855995)

Workaround: Use Apple Configurator 2 to create and install a configuration profile containing your root certificate.

Which seems to imply this is intentional. I wonder if the Configurator path is viable for mkcert.

If this is intentional, though, it seems weird it can be defeated with sudo security authorizationdb write com.apple.trust-settings.admin allow per https://github.com/actions/virtual-environments/issues/4519#issuecomment-970202641 (surely any malicious code would just do that?), and still doesn't explain why the script works for the GitHub runner setups.

We could mention com.apple.trust-settings.admin in the docs for CI/CD runners, but I'm worried about people just running it on their main machine.

@FiloSottile commented on GitHub (Apr 28, 2022): Whatever is going on is inconsistent with the `SecTrustSettingsSetTrustSettings` docs. > When making changes to system-wide trust settings, the user is prompted with an alert panel asking for an administrator’s name and password unless the calling process is running as root, in which case no further authentication is needed. https://developer.apple.com/documentation/security/1399119-sectrustsettingssettrustsettings @timsutton found the relevant entry in the Big Sur release notes: https://github.com/FiloSottile/mkcert/issues/322#issuecomment-868822285 > macOS Big Sur 11 beta improves system security by requiring an administrator password when a certificate trust settings change is made in the admin trust domain. Running as the root user alone is no longer sufficient to modify certificate trust. User trust domain settings continue to require confirmation by entering the password for the user’s account. This change may affect you if one of the following is true: > > You have written scripts which call /usr/bin/security add-trusted-cert -d ... as root. > > Your process runs as root and calls the SecTrustSettingsSetTrustSettings function to trust a certificate. > > Workflows that add trust settings in the admin trust domain, such as for an enterprise root certificate, may require modification if the user can’t authenticate as an administrator at the time settings are changed. (21855995) > > Workaround: Use Apple Configurator 2 to create and install a configuration profile containing your root certificate. Which seems to imply this is intentional. I wonder if the Configurator path is viable for mkcert. If this is intentional, though, it seems weird it can be defeated with `sudo security authorizationdb write com.apple.trust-settings.admin allow` per https://github.com/actions/virtual-environments/issues/4519#issuecomment-970202641 (surely any malicious code would just do that?), and still doesn't explain why the script works for the GitHub runner setups. We could mention `com.apple.trust-settings.admin` in the docs for CI/CD runners, but I'm worried about people just running it on their main machine.

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@timsutton commented on GitHub (Apr 28, 2022):

Hmm. The Configurator idea I think won't help here: besides requiring an extra download, Apple ID sign-in and "purchase" of a free app, you still can't install configuration profiles automatically starting with Big Sur either. Apple removed local profiles installation in the same OS release they also took away an officially-supported way to trust a root cert at the command line.

It seems weird about the workaround being possible, but I think there's a few possible reasons:

the security authorizationdb database is not a widely-known thing
they likely had to implement this restriction hastily because their security org has a lot of engineering power to impose demands on OS teams on short notice
they don't always coordinate these things so well that they don't leave other lesser-known workarounds working for a while

It is possible to afterwards revert the authorizationdb settings for com.apple.trust-settings.admin too, but I agree this is probably better off a thing to just document as an unsupported workaround that a user should do on their own if they accept the risk. IIRC reverting the settings is a more complicated command because the original setting's rules is a more complicated dictionary structure.

@timsutton commented on GitHub (Apr 28, 2022): Hmm. The Configurator idea I think won't help here: besides requiring an extra download, Apple ID sign-in and "purchase" of a free app, you still can't install configuration profiles automatically starting with Big Sur either. Apple removed local profiles installation in the same OS release they also took away an officially-supported way to trust a root cert at the command line. It seems weird about the workaround being possible, but I think there's a few possible reasons: * the `security authorizationdb` database is not a widely-known thing * they likely had to implement this restriction hastily because their security org has a lot of engineering power to impose demands on OS teams on short notice * they don't always coordinate these things so well that they don't leave other lesser-known workarounds working for a while It _is_ possible to afterwards revert the authorizationdb settings for `com.apple.trust-settings.admin` too, but I agree this is probably better off a thing to just document as an unsupported workaround that a user should do on their own if they accept the risk. IIRC reverting the settings is a more complicated command because the original setting's rules is a more complicated dictionary structure.

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@potatoqualitee commented on GitHub (Apr 29, 2022):

Don't know if this is too severe, but a documented flag can also be added like -forcemactrust and people can opt-in to the easier method in exchange for a few milliseconds of lessened security. I'd use that.

@timsutton -- seems you may also be suggesting to wait for workarounds to appear? also valid and clean(er).

@potatoqualitee commented on GitHub (Apr 29, 2022): Don't know if this is too severe, but a documented flag can also be added like `-forcemactrust` and people can opt-in to the easier method in exchange for a few milliseconds of lessened security. I'd use that. @timsutton -- seems you may also be suggesting to wait for workarounds to appear? also valid and clean(er).

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@timsutton commented on GitHub (Apr 29, 2022):

I was just suggesting that I think it's acceptable if the tool doesn't want to own a system configuration change that could be risky (and instead to document how users can do it at their own risk).

I'm not thinking 'risky' in the sense that one needs to temporarily reduce security policy, but risky in the sense that it's a change that Apple doesn't have a documented public API for and can easily break or change in the future, and that reverting the setting may take some time effort to get right. So if mkcert decided it would offer to make this change and also revert it afterwards, it'd be something to support in future years of macOS releases.

IMO the trickier details of the authorization database is the rules nomenclature and how to revert them after changing the configuration. 'eskimo' (an Apple engineer who posts a lot of very helpful replies on Apple's developer forums) has some good details provided here. The "allow" setting is easy to apply, and I think it's straightforward enough to put back a rule for the right (by piping the correct plist into stdin of security authorizationdb). But if those rules might change next OS release, that'd be not great. Maybe that's unlikely – but it's just the example of how this opens up a bit of a can of worms thanks to Apple having no simple and documented way to do this (outside of what they officially support for automation which is MDM-only).

@timsutton commented on GitHub (Apr 29, 2022): I was just suggesting that I think it's acceptable if the tool doesn't want to own a system configuration change that could be risky (and instead to document how users can do it at their own risk). I'm not thinking 'risky' in the sense that one needs to temporarily reduce security policy, but risky in the sense that it's a change that Apple doesn't have a documented public API for and can easily break or change in the future, and that reverting the setting may take some time effort to get right. So if `mkcert` decided it would offer to make this change and also revert it afterwards, it'd be something to support in future years of macOS releases. IMO the trickier details of the authorization database is the rules nomenclature and how to revert them after changing the configuration. 'eskimo' (an Apple engineer who posts a lot of very helpful replies on Apple's developer forums) has some good details provided [here](https://developer.apple.com/forums/thread/86537). The "allow" setting is easy to apply, and I think it's straightforward enough to put back a rule for the right (by piping the correct plist into stdin of `security authorizationdb`). But if those rules might change next OS release, that'd be not great. Maybe that's unlikely – but it's just the example of how this opens up a bit of a can of worms thanks to Apple having no simple and documented way to do this (outside of what they officially support for automation which is MDM-only).

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@sdavids commented on GitHub (Oct 30, 2023):

Sill an issue in Sonoma.

@sdavids commented on GitHub (Oct 30, 2023): Sill an issue in Sonoma.

kerem commented

2026-02-25 22:33:00 +03:00

Author

Owner

@BhaveshGujar111 commented on GitHub (Oct 7, 2024):

There is new issue occurs in new MacOS 15 version while adding certificates through MDM, before that it was working using below cmd
Using sudo prompt still asks to enter username and password

security authorizationdb write com.apple.trust-settings.admin allow ; security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" cert.cer ; security authorizationdb remove com.apple.trust-settings.admin

@BhaveshGujar111 commented on GitHub (Oct 7, 2024): There is new issue occurs in new MacOS 15 version while adding certificates through MDM, before that it was working using below cmd _Using sudo prompt still asks to enter username and password_ `security authorizationdb write com.apple.trust-settings.admin allow ; security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" cert.cer ; security authorizationdb remove com.apple.trust-settings.admin` ![image](https://github.com/user-attachments/assets/e0b8f824-82f0-4273-b6d9-e3a48282f371)

Rows
Columns

[GH-ISSUE #415] Starting from Big Sur 11.3 certificate installation requires user interaction #272