FiloSottile
Starting from Big Sur 11.3 certificate installation requires user interaction
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.
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.
got it working here : https://github.com/FiloSottile/mkcert/issues/412#issuecomment-976429667
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 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.
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.
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
I'll see who I can ping and let you know! Thanks for looking into this
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.
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 authorizationdbdatabase 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.
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).
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).
