Closed Sunspar closed 11 years ago
mkrautz
commented
11 years ago Hi Andrew,
In general, you should make sure you import a full certificate chain into the iOS app to be able to use CA-signed certificates.
When you view the certificate in Preferences, can you see the whole certificate chain? (You should be able to use the up/down arrows in the top bar to the right to switch between certificates in the same chain).
Sunspar
commented
11 years ago I don't appear to be getting that option. (I'm looking under Preferences > Certificate > desired certificate). All I have is the option to open a menu containing buttons for deleting / exporting the certificate; nothing else appears in the top-right.
I've run my .p12 file through openssl using: _openssl pkcs12 -info -in client.p12 > clientfull.pem and can verify that the full certificate chain seems to be there (I find certificate blocks that are exact matches to StarCom's certificate files downloaded from their website, along with the certificate and private keys given to me)
My Certificate file has the following form: My Certificate StarCom Class 1 Intermediate Authority StarCom Root CA My encrypted RSA private key
Does the private key need to be unencrypted in order to work on the iOS client?
For the record, I am importing the certificate by adding it to the "Mumble Documents" folder via iTunes and then adding it to the certificate list via the in-app interface.
mkrautz
commented
11 years ago Andrew,
Hmm! That's weird. Mumble for iOS supports encrypted .p12 files just fine - or should, at least. :-)
I'll have to do a more thorough test to figure out what's going on.
For now, could you go into Preferences -> Certificates -> + -> Show All Certificates
Then it'll show intermediate certificates in green.
It seems that either,
a) Mumble for iOS is not able to couple the certificates in the chain together. This would suggest that they imported just fine, but a bug in Mumble is making it impossible for it to actually see the chain.
b) The intermediate certificates were not imported at all. This would suggest something weird is happening during import, causing only the leaf to be imported.
If you could get back to me whether or not the intermediates are shown in green that'd be very helpful.
I'll have a closer look tomorrow. (I'm in the CEST time zone.)
Sunspar
commented
11 years ago There's unfortunately no difference between the certificate lists for "All Certificates": and solely identities. :(
mkrautz
commented
11 years ago Thanks! I'll take a closer look tomorrow.
mkrautz
commented
11 years ago @Sunspar
I just successfully imported a .p12 file with encrypted private key, exported via Windows's cert tool, into Mumble for iOS.
Seemingly the same certificates as yours, although openssl CLI prints them in a weird order for me:
What tool did you use to construct the .p12 file you used when importing? Windows's certificates panel? OS X keychain? OpenSSL?
Do you by any chance have a certificate with a similar Common Name in your Mumble app's keychain already? If that happens, the iOS keychain will fail to import.
Sunspar
commented
11 years ago I generated the request on the StartSSL website, but did not opt to supply my own CSR. I downloaded the certificates for the root and intermediate CA, and concatenated them into a file called cacerts.pem.
I then ran: openssl pkcs12 -export -in my.crt -infile my.key -certfile cacerts.pem -out mumbleCertificate.p12
entered all relevant passwords and the file created sucessfully.
I then ran it through: openssl pkcs12 - in mumbleCertificate.p12 -out mumbleCertificate.pem
and opened the file and saw all three certificates along with the encrypted RSA key.
I'm at a loss at this point as to what in the certificate might be causing the issue since it works just fine in the windows client. Would you be okay with me sending you my certificate / key? I am aware this renders the key pair compromised and am not using this for any other system.
mkrautz
commented
11 years ago Now that I know how you created the .p12 chain with Firefox/OpenSSL, I have a way to try to reproduce.
I'd like to try that before we take the next step.
mkrautz
commented
11 years ago Hi Andrew,
I returned to this issue today, and took a look at it with a fresh set of eyes. Very sorry it took so long.
I went through creating a new StartSSL identity in an attempt to reproduce the issue.
Once I got to the part where I needed to import it into the iOS app, I wanted to make sure I did not have any other certificates in the store that could conflict with it. Then, I saw the previous StartSSL certificate I had imported (earlier in this issue thread), but noticed something was amiss: its intermediates weren't actually present in my certificate store at all!
Seemingly, I must have imported my StartSSL cert and attempted to connect to my test server with my usual certificate, and was unable to reproduce the error. D'oh! My apologies for being a dumbass.
Anyway. Once I selected my StartSSL certificate and attempted to connect, once again, to my test server, the server aborted the handshake for the same reason you cited above.
The error is in Apple's SecPKCS12Import function. It only gives me back a single item, signalling that only the "identity" (cert and private key) was imported, but no intermediates or roots were processed.
At this point, I haven't dug deeper than the SecPKCS12Import function, so I can't really get detailed errors on a certificate level as of yet, but the next step will be to to try and parse the intermediates with SecCertificateCreateWithData. I believe that's the lowest level the APIs allow you to go. Unfortunately, that function only returns NULL to signal an error state, so I am not certain I can get anything useful out of that.
One solution to this issue is to switch to using OpenSSL routines to perform certificate import. This will also give us the benefit that we can import .pem intermediates individually, and other goodies. However, doing that means we cannot use the iOS keychain for storing certificates and private keys ("identities") and/or intermediate certificates, since that requires a SecIdentityRef, which can only be acquired via SecPKCS12Import on iOS.
Sigh.
mkrautz
commented
11 years ago I just tried it with the OS X Keychain.
I can import the .p12 just fine there.
I can export it as well. But the OS X keychain-exported version does not not work any better than the original, Firefox-exported one. I still only get the leaf and private key imported into the app.
mkrautz
commented
10 years ago @Sunspar Now available in 1.2.2 on the App Store. Enjoy.
Client Setup - iPad: iPad 4th Gen with Retina Display running latest version of iOS Mumble for iOS devices, version 1.2.1
Client Setup - Windows PC: Windows 8 running Mumble 1.2.4 and Murmur 1.2.4 (from the standard windows installer, no modifications made to either)
Server Setup: Murmur 1.2.4 running on Windows 8 (6.2.9200) with OpenSSL 1.0.1c.
The iPad client seems to be unable to connect to servers with third party signed certificates. Both the PC and iOS clients can connect to the server using self-signed certificates made by the PC client, and the iOS client can connect using its own generated certificate if none is supplied.
The PC client has no issues using the third party certificate to connect to the server.
In this case the third party certificate I am using was one of the free email certificates supplied by Comodo, although ones I use for other purposes from StartSSL (http://www.startssl.com/) do not work either.
Snippet of the server log from a failed iPad connection: