- #Create self signed certificate on mac server asks for keychain access how to#
- #Create self signed certificate on mac server asks for keychain access install#
- #Create self signed certificate on mac server asks for keychain access free#
It is crucial that you specify a good human-readable Common Name, because that’s what iOS uses for display purposes. When you run this on the command line, OpenSSL prompts you for a bunch of values to include in the certificate. Openssl req -x509 -new -nodes -key development-ca.key -sha256 -days 365 -out development-ca.crt I ran all these commands on the macOS Terminal command line. Here are the exact steps to create the right certificates that worked for me as of February 2020. I am starting a new project from scratch, and want to have a development server running, and my iOS and macOS clients can connect to it for development purposes. Let’s go ahead and assume I have nothing set up yet: no CA, no server certificates.
#Create self signed certificate on mac server asks for keychain access install#
You can install the CA cert as a trusted root in iOS and macOS development clients, and the individual server certificates issued by this CA are then trusted as well. So, we must now always have at least two certificates: the Certificate Authority (CA) who is the issuer, and then the actual TLS (web) server certificate.
If I understand things correctly, having “ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID” in the server certificate means that it cannot be simultaneously used as a CA certificate for itself, and there is no way to mark this certificate as trusted in iOS. I think it used to be possible to have a standalone self-signed web server certificate that worked with iOS, but this appears to no longer be the case. It’s better to cultivate a security mindset with all the channels secured at all times, even during development.Īpple continued in this direction by publishing requirements for trusted certificates in iOS 13 and macOS 10.15, and enforcing these requirements in the system. I think I’m doing myself a favor by not using any of those. There are some loopholes/emergency hatches left in the system and you can enable non-secure communications bypassing the TLS/certificate requirements, like NSAllowsArbitraryLoads and such.
#Create self signed certificate on mac server asks for keychain access free#
For publicly reachable servers, Let’s Encrypt is a great free solution, but it doesn’t help with development systems when you just want to hack something together quickly. API-s are typically served over HTTPS, secured with TLS and public key cryptography with keys and certificates.Īpple has aggressively been steering towards using TLS and HTTPS in all communications, and by default rejects non-TLS connections. I’m going to assume that you know in broad terms that we commonly use client-server systems, with mobile devices being the clients, and the servers serving some kind of API for the clients. Securing communication channels with TLS and certificates is a good protection against lots of the hostility. The Internet is a hostile, insecure place. So, here are the instructions mostly for my own future self, but why not anybody else too who might benefit from this.
There are a number of writeups available (linked at the end of this post), but I didn’t find one good resource with fully working instructions. There isn’t very clear info available about what you must do to set your server and certificates up the right way. It turns out Apple has hardened the security requirements for server certificates in iOS 13, and you must correctly set up development certificates to match the new requirements. I kept hitting TLS errors and API calls wouldn’t go through, even though I thought I had done everything correctly. I recently hit some bumps on the road when trying to set up a development API server for iOS 13 clients.
#Create self signed certificate on mac server asks for keychain access how to#
How to configure development server certificates for iOS 13 and Mac clients
0 kommentar(er)
