starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

OS X Client Uses System-Only Certificate Authority #402

New issue

Closed

opened 2026-02-20 19:24:18 -05:00 by deekerman · 13 comments

deekerman commented

2026-02-20 19:24:18 -05:00

Owner

Originally created by @emperor06 on GitHub (Nov 24, 2014).

Originally assigned to: @mkrautz on GitHub.

On OS X Mumble client (1.2.8) when the server prompts its ssl certificate, it is verified using the system keychain only.
OS X has actually 3 default keychains that hold our certificates: the user keychain (in ~/Library), a "custom system keychain" or computer keychain located in /Library, and an OS X System keychain in /System.
The user certificates go into the first one. The certificate authorities we want to add and trust go into the second one and are used globally (for all user, hence "system-wide". The last keychain simply cannot be changed (and should not) as it is provided and maintained by Apple (users should never alter /System).
A quick trace of the Mumble client shows that the only files checked are /System/Library/Keychains/SystemTrustSettings.plist and /System/Library/Keychains/SystemRootCertificates.keychain, which are basically that last system keychain we cannot alter.
As a result, when using our own certificate authority (which is correctly registered in the /Library system keychain) Mumble fails to verify the identity of the server since it cannot access the root certificate.

Affected OS:
Mac OS X (probably all versions). The Windows client correctly uses the system certificate store where the users can trust their own certificate authorities.

Expected Result:
Since my own CA is registered on all my computers, I do expect Mumble to connect my own server without any warning, which is actually the case on my Windows computer.

Actual Result:
The OS X client prompts me with the following warning:
Sever presented a certificate which failed verification..
The specific errors with this certificate are:
The root certificate of the certificate chain is self-signed, and untrusted
Do you wish to accept this certificate anyway?
(It will also be stored so you won't be asked this again.)

Possible Workaround:

I can manually review the server certificate from the warning popup and tell Mumble to accept the certificate anyway, which will tell Mumble to trust my own CA. But that defeats the purpose of trusting that CA system-wide. My own CA is already trusted on my Mac and I'd like Mumble to know about it (by looking into the correct keychain)
Install my CA into Apple's keychain in /System. This is a very bad idea. It will be reset on OS X update and I would have to hack the system keychain to do that (provided it's even feasible)
Use a certificate issued by CA already present in the Apple's trusted CA list which I won't do anyway since I do not trust what Apple trusts (yes, I do trust myself more than Apple :p)

Originally created by @emperor06 on GitHub (Nov 24, 2014). Originally assigned to: @mkrautz on GitHub. On OS X Mumble client (1.2.8) when the server prompts its ssl certificate, it is verified using the system keychain only. OS X has actually 3 default keychains that hold our certificates: the user keychain (in ~/Library), a "custom system keychain" or computer keychain located in /Library, and an OS X System keychain in /System. The user certificates go into the first one. The certificate authorities we want to add and trust go into the second one and are used globally (for all user, hence "system-wide". The last keychain simply cannot be changed (and should not) as it is provided and maintained by Apple (users should never alter /System). A quick trace of the Mumble client shows that the only files checked are /System/Library/Keychains/SystemTrustSettings.plist and /System/Library/Keychains/SystemRootCertificates.keychain, which are basically that last system keychain we cannot alter. As a result, when using our own certificate authority (which is correctly registered in the /Library system keychain) Mumble fails to verify the identity of the server since it cannot access the root certificate. Affected OS: Mac OS X (probably all versions). The Windows client correctly uses the system certificate store where the users can trust their own certificate authorities. Expected Result: Since my own CA is registered on all my computers, I do expect Mumble to connect my own server without any warning, which is actually the case on my Windows computer. Actual Result: The OS X client prompts me with the following warning: Sever presented a certificate which failed verification.. The specific errors with this certificate are: The root certificate of the certificate chain is self-signed, and untrusted Do you wish to accept this certificate anyway? (It will also be stored so you won't be asked this again.) Possible Workaround: 1. I can manually review the server certificate from the warning popup and tell Mumble to accept the certificate anyway, which will tell Mumble to trust my own CA. But that defeats the purpose of trusting that CA system-wide. My own CA is already trusted on my Mac and I'd like Mumble to know about it (by looking into the correct keychain) 2. Install my CA into Apple's keychain in /System. This is a very bad idea. It will be reset on OS X update and I would have to hack the system keychain to do that (provided it's even feasible) 3. Use a certificate issued by CA already present in the Apple's trusted CA list which I won't do anyway since I do not trust what Apple trusts (yes, I do trust myself more than Apple :p)

deekerman

2026-02-20 19:24:18 -05:00

closed this issue
added the
client

macOS

help wanted
labels

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@mkrautz commented on GitHub (Nov 24, 2014):

Thanks for creating a ticket for this.

We currently use Qt's own certificate verification code. Qt tries to use SecTrustSettingsCopyCertificates and SecTrustCopyAnchorCertificates (depending on symbol availability) in Security.framework to the root CAs it considers trusted.

This evidently doesn't include per-user anchors. The Windows code calls CertOpenSystemStore with the CERT_SYSTEM_STORE_CURRENT_USER flag. So user added root certificates are included.

Since Qt on Windows does this already, it's probably something they'd want to do for OS X as well.

There are two stores in addition to the system store we can use on OS X: admin and user. The admin store requires admin privileges to add and remove to (according to the docs. I'm not sure exactly what in the keychain that would correspond to). The user trust store would presumably just be root certs in the user's login keychain that are marked as trusted.

We should try and get a patch into mumble-releng for this, so we can try this out. Once we're sure it's OK, we should post it to Qt's gerrit and see what they think.

@mkrautz commented on GitHub (Nov 24, 2014): Thanks for creating a ticket for this. We currently use Qt's own certificate verification code. Qt tries to use SecTrustSettingsCopyCertificates and SecTrustCopyAnchorCertificates (depending on symbol availability) in Security.framework to the root CAs it considers trusted. This evidently doesn't include per-user anchors. The Windows code calls CertOpenSystemStore with the CERT_SYSTEM_STORE_CURRENT_USER flag. So user added root certificates are included. Since Qt on Windows does this already, it's probably something they'd want to do for OS X as well. There are two stores in addition to the system store we can use on OS X: admin and user. The admin store requires admin privileges to add and remove to (according to the docs. I'm not sure exactly what in the keychain that would correspond to). The user trust store would presumably just be root certs in the user's login keychain that are marked as trusted. We should try and get a patch into mumble-releng for this, so we can try this out. Once we're sure it's OK, we should post it to Qt's gerrit and see what they think.

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@emperor06 commented on GitHub (Nov 24, 2014):

That would be very nice. I'm up for any testing if needs be.
We can't blame Mumble or Qt for that since Apple tends to deprecate tons of their own API on each new OS X version. Some of the methods to access keychains have been revamped since OS X 10.7 :/ Thanks a lot for investigating this issue.

@emperor06 commented on GitHub (Nov 24, 2014): That would be very nice. I'm up for any testing if needs be. We can't blame Mumble or Qt for that since Apple tends to deprecate tons of their own API on each new OS X version. Some of the methods to access keychains have been revamped since OS X 10.7 :/ Thanks a lot for investigating this issue.

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@guruz commented on GitHub (Apr 15, 2015):

Hey guys, we're having the same issue for OS X in the ownCloud client.
@mkrautz Did you have something in gerrit already? Else I can attempt..

@guruz commented on GitHub (Apr 15, 2015): Hey guys, we're having the same issue for OS X in the ownCloud client. @mkrautz Did you have something in gerrit already? Else I can attempt..

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@mkrautz commented on GitHub (Apr 15, 2015):

@guruz We haven't patched this yet. Please go ahead :-) Once it's in gerrit or you a patch, please ping me, we'd like to add it as a patch ot our Qt 5 build for snapshot releases. :-)

@mkrautz commented on GitHub (Apr 15, 2015): @guruz We haven't patched this yet. Please go ahead :-) Once it's in gerrit or you a patch, please ping me, we'd like to add it as a patch ot our Qt 5 build for snapshot releases. :-)

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@mkrautz commented on GitHub (Jun 2, 2015):

@guruz Did anyone end up working on this? I am hacking on various QSsl things right now, so I can submit this to Gerrit soon, if no one else has done the work.

@mkrautz commented on GitHub (Jun 2, 2015): @guruz Did anyone end up working on this? I am hacking on various QSsl things right now, so I can submit this to Gerrit soon, if no one else has done the work.

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@guruz commented on GitHub (Jun 2, 2015):

@mkrautz Sorry no :) Just had the look at the code in https://github.com/owncloud/client/issues/2964#issuecomment-93400280 and did not find time to do anything. Please go on....

FYI @richmoore @peter-ha

@guruz commented on GitHub (Jun 2, 2015): @mkrautz Sorry no :) Just had the look at the code in https://github.com/owncloud/client/issues/2964#issuecomment-93400280 and did not find time to do anything. Please go on.... FYI @richmoore @peter-ha

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@guruz commented on GitHub (Jul 13, 2015):

@mkrautz Just checking in :) Did you have any success? Could go into 5.5.1 then..

@guruz commented on GitHub (Jul 13, 2015): @mkrautz Just checking in :) Did you have any success? Could go into 5.5.1 then..

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@mkrautz commented on GitHub (Jul 13, 2015):

No, sorry, haven't gotten to it yet. Currently working on getting settable Diffie-Hellman parameters in for 5.6.

@mkrautz commented on GitHub (Jul 13, 2015): No, sorry, haven't gotten to it yet. Currently working on getting settable Diffie-Hellman parameters in for 5.6.

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@bmisiak commented on GitHub (Jul 15, 2015):

El Capitan will prevent users with admin privileges from altering /System because of System Integrity Protection, so it seems like OP's workaround #2 goes out the window. :)

@bmisiak commented on GitHub (Jul 15, 2015): El Capitan will prevent users with admin privileges from altering /System because of System Integrity Protection, so it seems like OP's workaround #2 goes out the window. :)

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@mkrautz commented on GitHub (Jul 15, 2015):

Well, it's not like it's a particularly hard issue to solve, it just needs someone to do it. :-)

@mkrautz commented on GitHub (Jul 15, 2015): Well, it's not like it's a particularly hard issue to solve, it just needs someone to do it. :-)

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@guruz commented on GitHub (Nov 16, 2015):

Do you guys want to test https://codereview.qt-project.org/#/c/140966/2

FYI @danimo

@guruz commented on GitHub (Nov 16, 2015): Do you guys want to test https://codereview.qt-project.org/#/c/140966/2 FYI @danimo

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@danimo commented on GitHub (Nov 17, 2015):

Rather more generally https://codereview.qt-project.org/#/c/140966. There have been a few revisions on top.

@danimo commented on GitHub (Nov 17, 2015): Rather more generally https://codereview.qt-project.org/#/c/140966. There have been a few revisions on top.

deekerman commented

2026-02-20 19:24:25 -05:00

Author

Owner

@mkrautz commented on GitHub (Jan 12, 2016):

Thanks, patches are now merged into our Qt 5.5.1 build:
github.com/mumble-voip/mumble-releng@34dabf691a

@mkrautz commented on GitHub (Jan 12, 2016): Thanks, patches are now merged into our Qt 5.5.1 build: https://github.com/mumble-voip/mumble-releng/commit/34dabf691a49c1d78a013865515aa32f90944a6f