I created a Self-Signed CA and trust this certificate in Settings and it's working well in iOS 12. But after I upgrade the iOS version to 13, even the certificate trusted in Setting but still can't get it to working. So how do I fix this?
Nothing is known about your certificate but it might be that it is not meeting the new requirements introduced in iOS 13. Requirements for trusted certificates in iOS 13 and macOS 10.15 describes these and these include that RSA keys must be at least 2048 bits and it is no longer possible to use SHA-1 as signature algorithm.
I Happen to try something and it actually worked, Send the self signed .cer to the iphone with another configured email. The cert will be added to the iphone cert store. And Go to general setting then find Profil. Within the option you will see the name of the cert you just added and the option to configure it. Just do that in first place. Once done. Add the Exchange email account just like any other, it will prompt with certificate error but you will the option to continue and the account will be added correctly. I tried on Iphone 11 in the Mail App with Latest IOS.
Related
On our internal network, we use a self-signed CA certificate. This has worked fine for years, in both Safari and our iOS product, all the way through iOS 10. We simply install the CA certificate on any new device or simulator and everything works, even with ATS. This allows access to all of our internal test servers without having to trust each server individually.
Starting with iOS 11 the installed CA certificate no longer allows Safari or our app to trust the certificate for any of the servers. We receive the following relevant details with CFNETWORK_DIAGNOSTICS enabled for our app:
Error Domain=kCFErrorDomainCFNetwork Code=-1200
_kCFNetworkCFStreamSSLErrorOriginalValue=-9802
_kCFStreamErrorDomainKey=3
_kCFStreamErrorCodeKey=-9802
NSLocalizedDescription=An SSL error has occurred and a secure connection to the server cannot be made.
NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?
I spent considerable time trying to resolve this issue, scouring StackOverflow and the rest of the web. Although we use AFNetworking in our app, that seems to be irrelevant, as Safari no longer trusts these servers via the CA. Disabling ATS via NSAllowsArbitraryLoads allows access to the servers, but obviously isn't a solution.
No changes have been made to our -URLSession:didReceiveChallenge:completionHandler code, and we have a proper (worked for years) implementation of challenge response via challenge.protectionSpace.serverTrust.
I have re-evaluated and tested both the CA and server certificates every way I can think of, and they work everywhere except iOS 11. What might have changed in ATS for iOS 11 that could cause this issue?
While writing this question, I discovered the answer. Installing a CA from Safari no longer automatically trusts it. I had to manually trust it from the Certificate Trust Settings panel (also mentioned in this question).
I debated canceling the question, but I thought it might be helpful to have some of the relevant code and log details someone might be looking for. Also, I never encountered the issue until iOS 11. I even went back and reconfirmed that it automatically works up through iOS 10.
I've never needed to touch that settings panel before, because any installed certificates were automatically trusted. Maybe it will change by the time iOS 11 ships, but I doubt it. Hopefully this helps save someone the time I wasted.
If anyone knows why this behaves differently for some people on different versions of iOS, I'd love to know in comments.
Update 1: Checking out the first iOS 12 beta, it looks like things remain the same. This question/answer/comments are still relevant on iOS 12.
Update 2: Same solution seems to be needed on iOS 13 beta builds as well.
I've been struggling with this for 3 days now while attempting to connect to a local API running Laravel valet. I finally figured it out. In my case I had to drag and drop over the LaravelValetCASelfSigned.pem file from ~/.config/valet/CA/LaravelValetCASelfSigned.pem
After verifying the installing within the simulator I had to go to Settings > About > Certificate Trust Settings > and Enable the Laravel Valet VA Self Signed CN
Finally working!!!
Recommended solution is to install and trust a self-signed certificate (root). Assuming you created your own CA and the hierarchy of the certificated is correct you don't need to change the server trust evaluation. This is recommended because it doesn't require any changes in the code.
Generate CA and the certificates (you can use openssl: Generating CA and self-signed certificates.
Install root certificate (*.cer file) on the device - you can open it by Safari and it should redirect you to Settings
When the certificated is installed, go to Certificate Trust Settings (Settings > General > About > Certificate Trust Settings) as in MattP answer.
If it is not possible then you need to change server trust evaluation.
More info in this document: Technical Q&A QA1948 HTTPS and Test Servers
This has happened to me also, after undating to IOS11 on my iPhone. When I try to connect to the corporate network it bring up the corporate cert and says it isn't trusted. I press the 'trust' button and the connection fails and the cert does not appear in the trusted certs list.
Apple hand three categories of certificates: Trusted, Always Ask and Blocked. You'll encounter the issue if your certificate's type on the Blocked and Always Ask list. On Safari it show’s like:
And you can find the type of Always Ask certificates on Settings > General > About > Certificate Trust Setting
There is the List of available trusted root certificates in iOS 11
Blocking Trust for WoSign CA Free SSL Certificate G2
If you are not seeing the certificate under General->About->Certificate Trust Settings, then you probably do not have the ROOT CA installed. Very important -- needs to be a ROOT CA, not an intermediary CA.
I just answered a question here explaining how to obtain the ROOT CA and get things to show up: How to install self-signed certificates in iOS 11
I follow all recommendations and all requirements. I install my self signed root CA on my iPhone. I make it trusted. I put certificate signed with this root CA on my local development server and I still get certificated error on safari iOS. Working on all other platforms.
It appears that Apple has removed the ability to trust SSL certificates that are self-signed in iOS 10.
I created my own self-signed certificate and have a local web server that signed with my certificate. I must install my certificate in iOS for testing locally as I have developed an iOS application that needs to trust my certificate.
How can I install my self-signed certificate?
Good news, they haven't. If you just need this for development purposes, which it sounds like you do (and you shouldn't be using self-signed certificates in production anyway), you can install the self-signed certificate on your iOS devices manually. Following the equivalent FAQ for my iOS Web Bluetooth browser app:
Create your self-signed certificate and key files using openssl or however. Be sure it has the correct /CN “Common Name” for your local server, e.g. mycomputer.local.
Configure your webserver to use it (obviously) and check that it is working using a different client, such as a browser on a Mac.
Email your certificate to an email address you can access on your iOS device.
Tap on the attachment in Mail on your iOS device, this should now prompt you to install it. Do so.
You should now verify that it is installed by going to the Settings app then General -> Profile -> <Common Name>. The Profile menu probably won’t be there at all until you’ve installed the first certificate. The certificate should be marked Verified (it was verified by you when you installed it).
You might, like I did, have thought this would be enough. It isn’t. You now, really counter-intuitively, need to go to the setting General -> About -> Certificate Trust Settings and enable full trust for your certificate there as well. It’s such a weird place for that setting to be.
The installation of own root certificates changed at some point (maybe somebody can confirm, if it was at iOS 11).
What you need to do is with your Mac, get Apple Configurator 2 and create a profile containing your certificate. The resulting mobile profile file can be installed from Safari or email.
Ok so I have found these three answers: This one Revoked Certificate by Apple this one Your iOS Development certificate has been revoked? and this one Certificate has either expired or has been revoked and I get the same problem (A email from apple) every time that I use Xcode on one of the macOS devices that I have and then switch over and use Xcode on one of the other macOS device or vice-versa. and I think I know what's going on according to the answer at Your iOS Development certificate has been revoked? but is there any way that I can stop this from happening every time that I switch and use Xcode on the other device without needing to go through the process explained here? Certificate has either expired or has been revoked
If you are changing your mac, you have to create the .p12 file from certificate and install that .p12 onto new mac. Then there will be no problem regarding that certificate.
If you are familiar with how to create .p12 file from certificate.
Please check this link for certificate :-
https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html
you should create your own developpement certificate in your account and add all test devices you use.
but if you change your mac you should move certificate to the other mac or just create a new certificate for this mac.
We have an iOS app, which stopped installing with the following error:
"Unable to Download App [name] could not be installed at this time"
when trying to install on any iOS version 9 devices.
I used Xcode 6 to rebuild .ipa file and used plist and html files from the old build, but we still get the same error. Also I do not know how to recreate plist using Xcode 6.
Any help would be great
Make sure you properly export the ipa from Xcode, according to the Distribution Guide. Make sure to
select “All compatible device variants”. You can also select to create a new plist manifest at the export.
The server has to serve the html website over TLS/SSL. Is your certificate valid and trusted by iOS? Your server has support everything that App Transport Security requires, i.e. TLS 1.2 with forward secrecy.
Requirements for Connecting Using ATS
With ATS fully enabled, your app’s HTTP connections must use HTTPS and must satisfy the following security requirements:
The server certificate must meet at least one of the following trust requirements:
Issued by a certificate authority (CA) whose root certificate is incorporated into the operating system
Issued by a trusted root CA and installed by the user or a system administrator
The negotiated Transport Layer Security version must be TLS 1.2
The negotiated TLS connection cipher suite must support forward secrecy (FS) and be one of the following:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
The leaf server certificate must be signed with one of the following types of keys:
Rivest-Shamir-Adleman (RSA) key with a length of at least 2048 bits
Elliptic-Curve Cryptography (ECC) key with a size of at least 256 bits
In addition, the leaf server certificate hashing algorithm must be Secure Hash Algorithm 2 (SHA-2) with a digest length of at least 256 (that is, SHA-256 or greater).
if you update the ios with the latest ios 9.2 the issue will be solved.
Thanks.
I fixed the issue by creating a new distribution profile. After searching more on this, I found the following text on page 86 of in the Apple's iOS Deployment Reference (https://manuals.info.apple.com/MANUALS/1000/MA1685/en_US/ios_deployment_reference.pdf)
If your distribution certificate expires, the app won’t launch. Your
distribution certificate is valid for three years from when it was
issued, or until your Enterprise Developer Program membership expires,
whichever comes first. To keep your certificate from expiring, be sure
to renew your membership before it expires.
You can have two distribution certificates active at the same time,
with each independent from the other. The second certificate provides
an overlapping period in which you can update your apps before the
first certificate expires. When you request your second
Looks like the app has to be repackaged with a new distribution profile each year after renewing the membership.
Also this App still worked on iOS 9 when I used Xcode 6 to repackage it using new profile.
How do you update expired ssl certificates if ssl pinning is used on ios apps? It seems like only an app update would enable updating the certificate but then users who don't update the app will not receive this update.
The key is to understand the possible values for AFSecurityPolicy's pinningMode.
AFSSLPinningModeCertificate means that the certificate provided by the server must match exactly one of the pinned certificates, which by default are the certificates in your app bundle. This is the mode you are currently using.
AFSSLPinningModePublicKey means that the certificate provided by the server must contain the same public key as one of the certificates pinned by your app.
If you use AFSSLPinningModePublicKey and renew (update) your server certificate with the same keypair, your iOS app will continue to work without modification.
To address the second part of the question, yes users with old versions will be locked out.
To lower the impact, a common strategy is to include the new certificate alongside the soon to be expired certificate. This gives users a few 'buffer' versions they can be on and still have access after the changeover.