iOS 13 Syncs Calendar and Contacts but not Reminders

Nextcloud version: 16.0.5
Operating system and version: Arch Linux
Apache version: 2.4.41
PHP version: 7.3.10

The issue you are facing: I’m running iOS 13 on my iPhone and iPadOS on my iPad and trying to sync contacts, reminders, and calendars. Calendars and contacts sync perfectly. Reminders never appear. When configuring manually, SSL was enabled, port was 443, URL was https://ip.address.of.nextcloud/nextcloud/remote.php/dav/principals/users/ME. If I open the reminders app, it just says “My Lists” and there’s nothing there. I tried adding a new reminder to a list via the web interface on my Nextcloud machine to see if it triggered a sync but nothing happened. I’ve also tried deleting the account and adding it back several times. Currently, both devices are connected using the iOS configuration profile offered on the settings page for my user account and using a brand new device password. No difference.

I also read through this thread. I configured service discovery as specified in the Nextcloud documentation (admin page now shows “all checks passed”) but if I visit /.well-known/caldav on my phone, I get “This is the WebDAV interface” (exact same as on desktop) instead of the “password login forbidden” mentioned in the other thread (see Apache logs).

I also read through the GitHub issue regarding CalDAV on iOS 13 but unlike the users who posted there, I’m not seeing any reminders, possibly because I set up Nextcloud after updating to iOS 13.

I don’t have control over the local network, so I can only sync with my mobile devices by connecting my Nextcloud machine to my personal hotspot. Hence I access my server via IP address (see config file). I have a self-signed certificate and this is installed on my devices and trusted.

Is this the first time you’ve seen this error? Yes

Steps to replicate it:

  1. Set up CardDAV and CalDAV using the provided iOS configuration profile
  2. Open Reminders

The output of your Nextcloud log in Admin > Logging: Nothing of relevance.

The output of your config.php file in /var/www/nextcloud:

<?php
$CONFIG = array (
  'passwordsalt' => 'stuff',
  'secret' => 'stuff',
  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => 'my.local.ip.address',
    2 => 'hawking.local',
    3 => 'nextcloud.hawking.com',
    4 => 'ip.on.mobile.hotspot',
  ),
  'datadirectory' => '/var/www/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '16.0.5.1',
  'overwrite.cli.url' => 'http://localhost',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'memcache.local' => '\OC\Memcache\APCu',
  'dbuser' => 'stuff',
  'dbpassword' => 'stuff',
  'installed' => true,
  'instanceid' => 'stuff',
  'maintenance' => false,
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_sendmailmode' => 'smtp',
  'theme' => '',
  'loglevel' => 2,
);

(Machine hostname is hawking)

The output of your Apache log in /var/log/httpd/access_log:

mobile.device.ip.address - - [16/Oct/2019:23:48:38 +0200] "GET /status.php HTTP/1.1" 200 146
mobile.device.ip.address - ME [16/Oct/2019:23:48:38 +0200] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 553
mobile.device.ip.address - ME [16/Oct/2019:23:48:38 +0200] "PROPFIND /remote.php/webdav/Passwords HTTP/1.1" 207 1220
mobile.device.ip.address - - [16/Oct/2019:23:48:38 +0200] "GET /index.php/avatar/ME/128 HTTP/1.1" 304 -
mobile.device.ip.address - ME [16/Oct/2019:23:48:38 +0200] "REPORT /remote.php/dav/files/ME HTTP/1.1" 207 156
mobile.device.ip.address - ME [16/Oct/2019:23:48:38 +0200] "SEARCH /remote.php/dav HTTP/1.1" 207 6123
mobile.device.ip.address - ME [16/Oct/2019:23:48:38 +0200] "GET /ocs/v1.php/cloud/capabilities?format=json HTTP/1.1" 200 3682
mobile.device.ip.address - ME [16/Oct/2019:23:48:38 +0200] "GET /ocs/v2.php/apps/notifications/api/v2/notifications?format=json HTTP/1.1" 200 74
mobile.device.ip.address - ME [16/Oct/2019:23:48:38 +0200] "GET /ocs/v2.php/apps/files_sharing/api/v1/shares HTTP/1.1" 200 138
127.0.0.1 - - [16/Oct/2019:23:48:41 +0200] "GET /nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 200 74
mobile.device.ip.address - - [16/Oct/2019:23:48:42 +0200] "GET /nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 200 74
mobile.device.ip.address - - [16/Oct/2019:23:48:42 +0200] "GET /nextcloud/index.php/csrftoken HTTP/1.1" 200 104
127.0.0.1 - - [16/Oct/2019:23:48:44 +0200] "GET /nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 200 74
mobile.device.ip.address - - [16/Oct/2019:23:48:43 +0200] "GET /nextcloud/index.php/settings/user HTTP/1.1" 200 72719
mobile.device.ip.address - - [16/Oct/2019:23:48:44 +0200] "GET /nextcloud/index.php/css/icons/icons-vars.css?v=1571262524 HTTP/1.1" 200 113724
mobile.device.ip.address - - [16/Oct/2019:23:48:45 +0200] "GET /nextcloud/ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 200 74
mobile.device.ip.address - - [16/Oct/2019:23:48:46 +0200] "GET /favicon.ico HTTP/1.1" 406 -
mobile.device.ip.address - - [16/Oct/2019:23:48:47 +0200] "GET /favicon.ico HTTP/1.1" 406 -
mobile.device.ip.address - - [16/Oct/2019:23:48:47 +0200] "GET /favicon.ico HTTP/1.1" 406 -
mobile.device.ip.address - - [16/Oct/2019:23:48:48 +0200] "GET /.well-known/favicon.ico HTTP/1.1" 406 -
mobile.device.ip.address - - [16/Oct/2019:23:48:48 +0200] "GET /favicon.ico HTTP/1.1" 406 -
::1 - - [16/Oct/2019:23:48:49 +0200] "OPTIONS * HTTP/1.0" 200 -
mobile.device.ip.address - - [16/Oct/2019:23:48:45 +0200] "GET /nextcloud/cron.php HTTP/1.1" 200 20
mobile.device.ip.address - - [16/Oct/2019:23:48:56 +0200] "GET /.well-known/caldav HTTP/1.1" 301 254
mobile.device.ip.address - - [16/Oct/2019:23:48:56 +0200] "GET /nextcloud/remote.php/dav/ HTTP/1.1" 200 114

Uhh… I strongly suggest, that you never! post any sensitive information, like passwords on any forum and that you edit your post immediately and also change your mysql user and password at once!!

Aand… you will need to get DNS propperly working, because certificates only work with DNS names (on, that’s not strictly true, but they need to match the name, that your web server presents, so mostly this will not be an IP but a name). I am quite sure that iOS13 is veeery picky when it encounters a self-signed certificate or a non-matching one.

All of the entries with the value “stuff” aren’t real. Password salt, secret, SQL credentials. Not sure what else could be considered sensitive. Did I miss anything?

Regarding DNS: thanks, I’ll look into that. Any tips on what exactly I need to check? Because it’s strange that contacts and calendars sync but not reminders. Even if were a certificate issue, why would just this one service be more picky than the others?

At least I can confirm that the tasks on my NC instance get synchronized to the Reminders.app on my iOS13 iPhone. I haven’t used them ever, but creating a new task on my NC instance also synchs fine to my iPhone.

If I get the chance, I will try that today with a newly setup iPhone and use the provided profiles to connect that to my NC instance.

For reference: here is the according issue on github: https://github.com/nextcloud/server/issues/17190

So… I have checked this on either an iPhone running iOS13.1 and a Mac running Catalina, which had not before been connected to our NC instance and in both cases, there was zero issues. Either the calendar and reminder did work out of the box.

I’m stumped. I tried enabling iCloud reminders again so I could upgrade the list and now the group “Nextcloud” appears but no lists and no reminders in it. I tried deleting the Nextcloud profile and installing it again but it didn’t help (the group Nextcloud still appears though). Force refreshing from the Calendar app also does nothing. Thanks for testing though. I’ll update if I find anything new.

I can only provide the access logs from syncing calendars

ip.address.of.phone - - [18/Oct/2019:16:38:33 +0200] "PROPFIND /nextcloud/remote.php/dav/calendars/ME/contact_birthdays/ HTTP/1.1" 401 557
ip.address.of.phone - ME [18/Oct/2019:16:38:33 +0200] "PROPFIND /nextcloud/remote.php/dav/calendars/ME/contact_birthdays/ HTTP/1.1" 207 7729
ip.address.of.phone - - [18/Oct/2019:16:38:33 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/work/ HTTP/1.1" 401 557
ip.address.of.phone - ME [18/Oct/2019:16:38:33 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/work/ HTTP/1.1" 207 1636
ip.address.of.phone - - [18/Oct/2019:16:38:34 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/eth_timetable_20190921ics/ HTTP/1.1" 401 557
ip.address.of.phone - ME [18/Oct/2019:16:38:34 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/eth_timetable_20190921ics/ HTTP/1.1" 207 42362
ip.address.of.phone - ME [18/Oct/2019:16:38:34 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/eth_timetable_20190921ics/ HTTP/1.1" 207 42812
ip.address.of.phone - ME [18/Oct/2019:16:38:35 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/eth_timetable_20190921ics/ HTTP/1.1" 207 42777
ip.address.of.phone - ME [18/Oct/2019:16:38:36 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/eth_timetable_20190921ics/ HTTP/1.1" 207 15041
ip.address.of.phone - - [18/Oct/2019:16:38:36 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/ethz/ HTTP/1.1" 401 557
ip.address.of.phone - ME [18/Oct/2019:16:38:36 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/ethz/ HTTP/1.1" 207 3239
ip.address.of.phone - - [18/Oct/2019:16:38:37 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/personal/ HTTP/1.1" 401 557
ip.address.of.phone - ME [18/Oct/2019:16:38:37 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/personal/ HTTP/1.1" 207 18270
ip.address.of.phone - ME [18/Oct/2019:16:38:38 +0200] "REPORT /nextcloud/remote.php/dav/calendars/ME/contact_birthdays/ HTTP/1.1" 207 18930
ip.address.of.phone - - [18/Oct/2019:16:38:38 +0200] "PROPFIND /nextcloud/remote.php/dav/calendars/ME/inbox/ HTTP/1.1" 401 557
ip.address.of.phone - ME [18/Oct/2019:16:38:38 +0200] "PROPFIND /nextcloud/remote.php/dav/calendars/ME/inbox/ HTTP/1.1" 207 421
ip.address.of.phone - ME [18/Oct/2019:16:38:38 +0200] "PROPFIND /nextcloud/remote.php/dav/calendars/ME/inbox/ HTTP/1.1" 207 421
ip.address.of.phone - - [18/Oct/2019:16:38:54 +0200] "REPORT /nextcloud/remote.php/dav/principals/users/ME/ HTTP/1.1" 401 557
ip.address.of.phone - ME [18/Oct/2019:16:38:54 +0200] "REPORT /nextcloud/remote.php/dav/principals/users/ME/ HTTP/1.1" 207 560
ip.address.of.phone - - [18/Oct/2019:16:38:54 +0200] "PROPFIND /nextcloud/remote.php/dav/calendars/ME/ HTTP/1.1" 401 557
ip.address.of.phone - ME [18/Oct/2019:16:38:54 +0200] "PROPFIND /nextcloud/remote.php/dav/calendars/ME/ HTTP/1.1" 207 24908
ip.address.of.phone - ME [18/Oct/2019:16:38:54 +0200] "PROPFIND /nextcloud/remote.php/dav/calendars/ME/inbox/ HTTP/1.1" 207 421
ip.address.of.phone - ME [18/Oct/2019:16:38:54 +0200] "PROPFIND /nextcloud/remote.php/dav/calendars/ME/inbox/ HTTP/1.1" 207 421

Hi @Arc676

You may like to have a look at:

  1. The Issue Template Nextcloud app to prefill github issue with current server information.
  2. The ongoing discussion on Privacy issue: Issue template is to(o) “chatty” #27
  3. Issue Template in the Nextcloud App store.

Hope this helps in reporting issues.

Unfortunately, I cannot address the specific issue with iOS 13 and iPhone you are mentioning.

To me, it seems to be a certificate issue! Maybe the reminder app does stronger cert checking. I can reproduce the lack of sync on my home devices, that have a self signed certificate.
I also have a nextcloud server on a officially signed domain: There, I have no problems with syncing!

1 Like

Thank you so much for testing this! It’s certainly weird that Reminders and Calendar somehow have different standards, but at least this confirms that it is indeed a certificate issue.

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

EDIT:

  • 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 your.servers.domain.com with domain name of server and 10.0.0.1 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            = some@mail.com


# 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:your.servers.domain.com, DNS:10.0.0.1
# nsComment         = "OpenSSL Generated Certificate"
extendedKeyUsage    = serverAuth


# RFC 5280, Section 4.2.1.12 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:your.servers.domain.com, DNS:10.0.0.1
nsComment             = "OpenSSL Generated Certificate"


# RFC 5280, Section 4.2.1.12 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       = example.com
# DNS.2       = www.example.com
# DNS.3       = mail.example.com
# DNS.4       = ftp.example.com


# 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       = 127.0.0.1

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.

2 Likes

Hi
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
Bart

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/com.apple.xbs/Sources/libressl/libressl-56.60.2/libressl-2.8/crypto/conf/conf_def.c:563:line 21

Any help is appreciated for this!

Best,

G.

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):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            [XX:XX:XX:XX:XX...]
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = [ISSUER_COUNTRY_CODE], O = [ISSUER_ORGANIZATION], CN = [ISSUER_COMMON_NAME]
        Validity
            Not Before: Dec 11 10:10:10 2020 GMT
            Not After : Mar 10 10:10:10 2021 GMT
        Subject: [COUNTRY_CODE], O = [ORGANIZATION], CN = [COMMON_NAME]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
               RSA Public-Key: (4096 bit)
                Modulus:
                    [XX:XX:XX:XX:XX...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:[XX:XX:XX:XX:XX...]

            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Key Identifier: 
                [XX:XX:XX:XX:XX...]
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name: 
                DNS:domain1.example.com, DNS:domain2.example.com, DNS:domain3.anotherexample.com
    Signature Algorithm: sha256WithRSAEncryption
         [XX:XX:XX:XX:XX...]

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):
    Validity
       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!):
    Subject: [COUNTRY_CODE], O = [ORGANIZATION], CN = [COMMON_NAME]
    
  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:
    DNS:domain1.example.com, DNS:domain2.example.com, DNS:domain3.anotherexample.com
    

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.

Best,

G.

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 - Pastebin.com

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?