The CardDAV server I'm trying to connect to uses a self-signed certificate. Unfortunately I cannot do anything about it.

In previous OS X versions, when connecting to this server the system asked if I want to connect using this insecure certificate. I could accept and continue.

When trying the same thing in the current OS X version, this does not work. The Contacts.app only show a connection issue.

When looking into the logs in Console, I could find this error:

02/12/15 00:55:39,637 Contacts[39186]: [CardDAVPlugin-ERROR] -getPrincipalInfo:[_controller discoverServer https://user@host:port(null)] 
    Error Domain=NSURLErrorDomain
    "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?

No alert, no asking for proceeding anyways.

Now I thought I might be able to download the certificate, add it to the keychain and set the default trust to "Always Trust".

echo -n | openssl s_client -connect host:port | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > carddav.cer

Got the certificate, added it to the keychain, set the trust and tried again – bummer: Same error again and still no confirmation dialog.

Now my question is: Is there any way to allow Contacts.app to connect to my server or to bring back the confirmation dialog?


As requested, here are my SSL connection details:

depth=0 CN = , O = , OU = , ST = , C = , L = , emailAddress = 
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = , O = , OU = , ST = , C = , L = , emailAddress = 
verify return:1
Certificate chain
 0 s:/CN=/O=/OU=/ST=/C=/L=/emailAddress=
Server certificate
No client certificate CA names sent
SSL handshake has read 1198 bytes and written 658 bytes
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
    Protocol  : SSLv3
    Cipher    : AES256-SHA
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1449069604
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
  • Is the self signed certificate using SSL or TLS protocol? What version of SSL or TLS? What cipher suite is being used? Can you provide the output of openssl s_client -connect host:port Commented Dec 2, 2015 at 14:53

2 Answers 2


According to the Security Enhancements section of the OS X 10.11 pre-release notes on Apple's Developer web site

App Transport Security (ATS)

App Transport Security (ATS) enforces best practices in the secure connections between an app and its back end. ATS prevents accidental disclosure, provides secure default behavior, and is easy to adopt; it is also on by default in OS X v10.11 and iOS 9. You should adopt ATS as soon as possible, regardless of whether you’re creating a new app or updating an existing one.

If you’re developing a new app, you should use HTTPS exclusively. If you have an existing app, you should use HTTPS as much as you can right now, and create a plan for migrating the rest of your app as soon as possible. In addition, your communication through higher-level APIs needs to be encrypted using TLS version 1.2 with forward secrecy. If you try to make a connection that doesn't follow this requirement, an error is thrown. If your app needs to make a request to an insecure domain, you have to specify this domain in your app's Info.plist file.

  • As a developer I know about that. But this is not a developing question. I am asking about a system provided service. I hope that OS X is still downwards compatible or there might be a possibility to achieve that. Commented Dec 2, 2015 at 15:37

Open the Keychain Access.app, and add your self-signed certificate to the login group. Then double-click it, expand the Trust section and set Always Trust for everything.

To pull your self-signed certificate click the lock 🔒   icon to the left of the browser URL bar (Safari/Chrome), pick Certificate and the drag the big certificate icon into Finder. Next, from Finder you can drag it into Keychain Access.app under login (or System).

OR from the command line:

sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" my-self-signed-cert.pem
  • This did not work as stated in thequestion. Commented Aug 1, 2021 at 10:51
  • @JulianF.Weinert: even when added under the login group?
    – ccpizza
    Commented Aug 1, 2021 at 13:32
  • I'm really sure, since I never really used other keychains. But it also has been 6 years and I don't have access to this server anymore, thus not having to rely on self signed certs, which is for the best :) Commented Aug 1, 2021 at 13:35
  • 1
    I see, then, unless there is no control over the client, the only viable answer would be getting a valid cert, which is tricky for intranet but still doable, e.g. blog.heckel.io/2018/08/05/… Using a more lenient client could be simpler though (e.g. infcloud).
    – ccpizza
    Commented Aug 1, 2021 at 13:40
  • @JulianF.Weinert: another easy-n-dirty option (does not answer your exact question, i.e. not a self-signed cert): use a valid certificate for any domain you own (free or paid) and then edit your machine's /etc/hosts to spoof that domain on your LAN with my-registered-domain.com (both domain and port must match); this is ugly but simpler than registering intranet sub-domains, etc. (...you'll also need to figure out ways to access the domain you spoofed in case you need it); a domain can be easily set up for free with something like duckdns
    – ccpizza
    Commented Aug 29, 2021 at 11:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .