iOS 13 Syncs Calendar and Contacts but not Reminders

I can confirm that.

selfsigned certificate:

  • calendars do sync
  • reminders are empty and do not sync

trusted certificate (letsencrypt):

  • calendars do sync
  • reminders do sync


  • addressbook sync works in both cases
1 Like

Ok, we found the solution (many thanks to @Bernie_O ): the post by “fixitnowyes” on Apple-discussions gives the necessary instructions to create a certificate which will be accepted by my iOS 13 devices! I am quite happy to have syncing reminders on my local server again.
Don’t foget to import the new certificate to the iOS device and switch on the “trust” (settings / general / about / scroll down to “certificate trust settings”).

Edit: This is the content of the above-mentioned post or - if german-speaking - read a Blog-Artikel darüber :

Create a file “server-selfsigned-CA.cnf” with content (replace with domain name of server and with IP of your server):

[ req ]
default_bits        = 4096
default_keyfile     = server-selfsigned-CA.key
default_md          = sha256
default_days        = 824
encrypt_key         = no
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only
prompt              = no

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
#   Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
OU                     = Company Inc.
countryName            = DE
stateOrProvinceName    = Berlin
localityName           = Berlin
organizationName       = Company Inc.

# Use a friendly name here because it's presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName              = aFriendlyName
emailAddress            =

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
subjectKeyIdentifier      = hash
#authorityKeyIdentifier    = keyid,issuer
authorityKeyIdentifier    = keyid:always,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints    = critical, CA:TRUE
keyUsage            = critical, digitalSignature, keyEncipherment, cRLSign, keyCertSign
subjectAltName      =, DNS:
# nsComment         = "OpenSSL Generated Certificate"
extendedKeyUsage    = serverAuth

# RFC 5280, Section makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage    = serverAuth, clientAuth
extendedKeyUsage    = TLS Web Server Authentication

# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
subjectKeyIdentifier  = hash
basicConstraints      = CA:FALSE
keyUsage              = digitalSignature, keyEncipherment
subjectAltName        =, DNS:
nsComment             = "OpenSSL Generated Certificate"

# RFC 5280, Section makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
#extendedKeyUsage    = serverAuth, clientAuth

# [ alternate_names ]
# DNS.1       =
# DNS.2       =
# DNS.3       =
# DNS.4       =

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       =

Generate a new certificate using the .cnf file:

sudo openssl req -config server-selfsigned-CA.cnf -new -x509 -out server-selfsigned-CA.crt -days 825

You can check if the certificate was created correctly with:

openssl x509 -in server-selfsigned-CA.crt -text -noout

Import the file “server-selfsigned-CA.crt” to iOS device (I used a SMB connection and the new “files”-app).

On the iOS device, go to settings and install the certificate.

Then, go to settings / general / about / scroll down to “certificate trust settings” and switch on trust for the certificate.

And that’s it, reminders app will sync again.


This is a quite old post but still one of them that I found for my problem. I have read all possible solutions at Nextcloud, Github and Apple forums but can’t get it working.

‘Old’ story I know, but what I did:

  • Upgrade Mojave to Catalina (yes, I wait always a half year to do upgrades out of safety)
  • Reminders never asked to update the database.
  • Upgrade Nextcloud 17 to 18 (later version)

What’s the problem:

  • All went fine except Reminders do not sync anymore.

What I have researched:

  • All possible solutions at Nextcloud, Github and Apple forums but can’t get it working.

What I want to ask:

  • How to check if the Reminder database update was done yes or no?
  • A step by step guide how to install the certificate?
  • If that’s not what I need; other tip and tricks.

Kind regards

Hi all,
I am having the same issue as @bartatgit. After creating the certificate as indicated, sync works under iOS, but not macOS Big Sur. This is despite adding the certificate to the mac keychain (see picture).

Schermata 2021-01-02 alle 14.51.25

@Bernie_O, would you have some input on this? Note: I have tried to use the information from the German article, but the terminal issues the following error at the first command line (openssl req…):

error on line 21 of openssl-ca.cnf
4746624684:error:0EFFF068:configuration file routines:CRYPTO_internal:variable has no value:/AppleInternal/BuildRoot/Library/Caches/ 21

Any help is appreciated for this!



Unfortunately I did not update to Big Sur yet, but a friend of mine did and reminders do get synchronised with his self signed certificate (created like described above).

Looks like you create the certificate on Mac OS? I am sorry, I can‘t help with that. I always used OpenSSL on a linux machine (currently OpenSSL 1.1.1d).

However, I can post the text output of a certificate and describe more in detail which requirements need to be met. The following command displays the content of a webserver certificate as text:

openssl x509 -in webserver_certificate.pem -noout -text

This is an example of an output (shortened):

        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha256WithRSAEncryption
            Not Before: Dec 11 10:10:10 2020 GMT
            Not After : Mar 10 10:10:10 2021 GMT
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
               RSA Public-Key: (4096 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 

            X509v3 Basic Constraints: 
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Key Identifier: 
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name: 
    Signature Algorithm: sha256WithRSAEncryption

The most critical bits are:

  1. Make sure the Signature Algorithm is part of the SHA-2 family (this is twice in the certificate, once for the issuer, once for the certificate. Both need to be SHA-2!):
    Signature Algorithm: sha256WithRSAEncryption
  2. Make sure, the certificates validity is shorter than 825 days (mine actually is only 90 days - just like letsencrypt):
       Not Before: Dec 11 10:10:10 2020 GMT
       Not After : Mar 10 10:10:10 2021 GMT
  3. Make sure, that there are no DNS names in the Common Name (CN) under Subject (they need to be in the x509v3 extensions - see: 6.) (of course DNS-names in the CN of the Issuer are also not allowed!):
  4. Make sure, the key is at least 2048 bit long (mine is 4096) (Note, that also the key of the issuer needs to be at least 2048 bit long!):
    RSA Public-Key: (4096 bit)
  5. Make sure, the Extended Key Usage contains TLS Web Server Authentication (this is the id-kp-serverAuth OID):
    X509v3 Extended Key Usage: 
       TLS Web Server Authentication, TLS Web Client 
  6. Make sure that the desired DNS-Names are also in the X509v3 extensions (and not in the common name - see: 3.)
    X509v3 Subject Alternative Name:,,

I hope this is of a little help for you.

Thanks a lot for the quick reply, @Bernie_O. Unfortunately, I am a bit out of my depth here and cannot seem to reconcile your message with the code given by @macnex (and which I have used successfully for my iOS certificate).

For instance, right from the beginning, the signature is only mentioned once in the template certificate; is this an issue?

You mentioned a friend who has updated to Big Sur and managed to get the synchronisation to work with his own self-signed certificate. Is it possible to have a look at his certificate (cleaned from private data)? This would be most helpful.



I can confirm that a certificate created as stated above (created with OpenSSL, which can also be installed on MacOS e.g. with Homebrew) does work fine for all synchronisations with MacOS 11 Big Sur and iOS 14.

Thanks @macnex, this is reassuring. The question now is how to get this to work, as @bartatgit and I both seem to have problems doing so.

Openssl does not seem to be the problem, since I used it successfully to create a first certificate (using almost exactly the code @macnex gave in the October 2019 message above) and that certificate worked with iOS (although it was indicated as unsigned at first).

However, the very same certificate, when imported into the macox keychain is marked as “not trusted”. And even when I mark it as “trusted” myself and force a re-synchronisation (cf. System preferences > internet accounts > caldav > remove reminders, re-add reminders), the synchronisation process does not work (the account appears in the Reminders app but no reminders actually sync).

I tried using @Bernie_O’s comments to modify the cnf file a little. For instance, adding alternative names (which are greyed out in the template certificate). But that seems like a minor change.

EDIT: please disregard the former openssl error; I’m ashamed to admit that I was running the command line from a different directory :S Moved shell to the right directory and openssl successfully creates the certificate.

The problem remains that the certificate, once imported into the macos keychain, is marked as untrusted and that manually trusting it does not allow synching.

Here is the information I get from the keychain:

And here is the cnf file I use: server-selfsigned-CA-macos -

Any ideas, @macnex or @Bernie_O?

Sorry for the late reply, I have been busy with other things.

That could indeed be a problem, as apple states that “TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm.” (HT210176)

I checked again the post of @macnex above, in which he describes how to create a valid certificate. This was an early stage in testing. I am really sorry, that I didn’t notice this earlier and made you spend some time setting up certificates in an (for me) obsolete way I would not recommend anymore.

The way I create my certificate now is meanwhile different. I now create a certificate authority (CA) which signs my server certificates. This way I just have to import the CA-certificate only once and as long as it is valid and trusted, server certificates signed from this CA are trusted as well (the CA-certificates validity doesn’t matter - it can be much longer than 825 days. Apple just cares about the validity of the webserver certificate). I think, that is the reason why my webserver-certificate has the signatures mentioned twice (once from the issuer (CA) and once from the certificate itself).

Can you try to create a CA and webserver certificate like described in my Blogpost here? I know, it is in german, but with the help of a translator I think it should be possible to follw. The commands are international anyway and if you don’t understand some sections, I can try to help.

One last thing: in another thread in this forum about this subject, a user states that the synchronization worked after disabling little snitch. Do you use little snitch or another app that is monitoring and filtering/blocking network-traffic?

Thanks for the detailed reply, @Bernie_O, and no worries about the delay – we’re all volunteers here and help is always appreciated.

I had previously tried to follow the post’s steps but ran into the error I mentioned above. Since it now appears the error was my own, I will try again.

Beyond this, I am indeed using Little Snitch. Good to know this may be a cause for concern here; I’ll keep an eye on @factor4’s reply.


EDIT: I already wrote on the Blogpost’s page :wink:

1 Like

I saw your edit just now. Unfortunately something went wrong and your comment seems to not get stored on the Blog-Server.
Are there any news? Did you get the reminder sync to work?

Hey @Bernie_O, thanks for following up on this here and sorry the message did not work out.

So I do indeed get stuck. The first commands and the creation of the folders/files goes well, and I personalised the openssl-server.cnf file as necessary (I think).

However, the next command (openssl req -x509 -config openssl-ca.cnf -sha256 -nodes -out cacert.pem -outform PEM -days 7300) gets the terminal to hang indefinitely. It’s not actually failing like before (I am indeed in the right folder — /Download/SSL2, for me) and there’s no error message, but it just hangs and that’s it.

Any ideas? Is it an issue that I am using zsh?

I can confirm that the command just hangs under MacOS and I have no idea why. MacOS uses libressl - a fork of openssl (you can check that with openssl version). According to the developers the api should be identical to the openssl api, so the commands should actually work. As I am always using a linux box to create the certificates, I am very sorry that can’t help here.

No, I don’t think zsh is the problem here, as it does nothing else than invoking openssl (aka libressl).

P.S.: meanwhile I found your blog-comment in the spam and was able to restore it!

Ok, then it’s not just me, that’s always a relief.

Actually, following your earlier comment, I checked my version of openssl and, indeed, it’s libressl 2.8.3 (if my memory is correct). I therefore installed homebrew and openssl, to try openssl’s most recent version, but macOS keeps on using libressl. Would you know how to tell macOS to use the installed openssl instead? Maybe that’d be a fix.

homebrew installs the openssl binary in /usr/local/opt/openssl/bin/. You can check, if it is working with

/usr/local/opt/openssl/bin/openssl version

If that outputs something like OpenSSL 1.1.1i 8 Dec 2020 you are ready to go. Just use the full path to openssl for each command. The first command would then look like:

/usr/local/opt/openssl/bin/openssl req -x509 -config openssl-ca.cnf -sha256 -nodes -out cacert.pem -outform PEM -days 7300

Let me know if that works!

It does, thanks! I’ll keep going and ping back when all is done or if things get stuck again.

1 Like

Well, that did not take long. Of course, now all the openssl commands work successfully.

Next step is to add servercert.pem and serverkey.pem to my server. Any idea on how to do this for Webo Nextcloud Hosting? A cursory look at the nextcloud support pages did not yield much information :frowning:

No, sorry. I don’t use Webo. You have to ask your hoster.

So there is good news and bad news.

The bad news is that I have not heard from my hoster, and that, therefore, this whole process of creating the CA has, for now, been in vain.

The good news is that, somehow, the sync now works. I do not have a real explanation for that. I just updated macOS (to version 11.2 20D62), but since I had not checked the sync in a little while, I cannot say for sure that this is what made the difference.

At any rate, thank you all for the help and I’ll keep an eye on the sync in case it breaks again.

1 Like