To see the digest-algorithm used, you have to display the certificate parameters using the command line,
/certificate print detail where common-name~"vpn".
But when signing certificates, RouterOS normally uses SHA-256, which is from the SHA-2 suite, so it fits those requirements.
As for the rest, I suppose you've used the DNS name of the Mikrotik, which is used in the Subject-Alt-Name of the certificate, also to configure the remote server field in the Apple VPN client?
Don't fall to false hopes - I don't have a working setup, I'm just trying to help.
And the log from the Apple says authentication failed but doesn't explain whether it got a NOTIFY from the Mikrotik or it didn't like Mikrotik's authentication information. So what does Mikrotik's IPsec log show?
[admin@MikroTik_RB4011] > /certificate print detail where common-name~"vpn"
Flags: K - private-key, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted
0 K I name="VPN_Server" digest-algorithm=sha256 key-type=rsa country="NZ" state="xxxx" organization="Alex's House" common-name="vpn.xxxx.me" key-size=2048 subject-alt-name=DNS:vpn.xxxx.me days-valid=3650
trusted=no key-usage=tls-server ca=Certification_Authority serial-number="2A5A845219E41AEE" fingerprint="769b7d9305e9e21517fbb3652f9exxxxxxdaaaxxxxxxxxxxxxxxxxxxxx"
akid=0c3ee70764xxxxxxxxxxxxxxxxxxxxxx skid=1f4da3ef9bd3125cxxxxxcxxxxxxxxxxxxxxxxxxx invalid-before=nov/05/2020 21:11:12 invalid-after=nov/03/2030 21:11:12 expires-after=506w9h53m22s
I have this one set up, sindy:The log from the Mikrotik shows that the Apple uses its private IP address as its identifier (ID_I), so the Mikrotik cannot find a corresponding row in /ip ipsec identity . But if I understand it right, this actually indicates that the Apple device doesn't consider its own certificate fit for its own authentication. What are the key-usage items of the certificate you've generated for the Apple? Mikrotik is happy with the tls-client value in the initiator's certificate, but the Apple may require one of those ipsec-something ones.
As I've got no Mac/iPhone laying around, let alone with the OS version in question - can you post the window that opens if you click [Authentication Settings...] in the window you've already posted?
Thank you Sindy but got the same results, here are the logs with standard settings no specific user cert is chosen and remote-id is set to auto, this is when I now get "peer id doesn't match cert "I'd say match-by=certificate remote-certificate=the-one-of-the-client should do the trick with either remote-id=ignore or remote-id=auto. But it's just a guess, maybe auto is necessary, as in fact the header of the certificate is sent as the ID, as the log should show you. Maybe Apple does that differently - again, log will show.
But there is actually nothing bad about ignoring the remote ID (unless you need to choose a particular mode-config and/or policy-template-group per individual client) if the client is authenticated by certificate - the connection will fail if the client presents an invalid certificate, or one signed by an unknown CA, it's just that the same identity row will be chosen for multiple clients.
23:33:19 ipsec ipsec: processing payload: ID_I 23:33:19 ipsec ipsec: ID_I (ADDR4): 10.10.0.19 23:33:19 ipsec ipsec: processing payload: ID_R 23:33:19 ipsec ipsec: ID_R (FQDN): vpn.xxx.me 23:33:19 ipsec ipsec: processing payload: AUTH 23:33:19 ipsec ipsec: processing payload: CERT 23:33:19 ipsec ipsec: got CERT: CN=AlxxxxxxVPN,C=NZ,ST=Wellington,L=,O=Alex's House,OU=,SN=
You may have misunderstood me. The identity row, even if just a single one is attached to a peer, is always matched on either the remote ID or the certificate (depending on the setting of the match-by parameter). So if remote-id is set to ignore, the row will match on any ID_I received, and the only thing to be checked about the certificate is whether it has been signed by a known certification authority. If you set match-by=certificate, the certificate received from the initiator peer is used also to find the matching identity row, so it must be stored on the Mikrotik and the remote-certificate of the identity must point to it. BTW, in this case, only the header fields of the certificate is compared, so even if the one stored at Mikrotik expires, a valid (renewed) certificate with the same header fields is properly matched.
The log shows that the Apple does not send a reference to the certificate as its ID, and keeps sending the IP address as ID_I:
formatted code23:33:19 ipsec ipsec: processing payload: ID_I 23:33:19 ipsec ipsec: ID_I (ADDR4): 10.10.0.19 23:33:19 ipsec ipsec: processing payload: ID_R 23:33:19 ipsec ipsec: ID_R (FQDN): vpn.xxx.me 23:33:19 ipsec ipsec: processing payload: AUTH 23:33:19 ipsec ipsec: processing payload: CERT 23:33:19 ipsec ipsec: got CERT: CN=AlxxxxxxVPN,C=NZ,ST=Wellington,L=,O=Alex's House,OU=,SN=