Jafar, thank you very much again.
On 20.08.2018 23:20, Jafar Al-Gharaibeh wrote: > The issue does have something to do with non-matching proposals. It is > just that for signature schemes prior to version 5.3 the signature > constraints were not enforced. In your configuration you have : > > leftauth=rsa-4096-sha512 > rightauth=rsa-4096-sha512 > > > That means you expect the certificates at both ends to use use at > least 4096 RSA keys and sha512 for signature schemes. You had the > setting all the time but it wasn't being enforced prior to 5.3, but now > it is. Instead of fixing it by turning > > signature_authentication_constraints > > off, I would generate new certificates with that strength if you want it > that strong, or just lower your constraints in left/rightauth to match > your existing certs. see left/rightauth at [1]. Perhaps I have been not clear enough, but I believe that in my previous post I have described how I created the certificates when initially configuring that VPN. To quote myself (from my previous post): "Furthermore, when initially configuring the VPN between me and my client (about 2 years ago), I have newly created *all* certificates involved from scratch, using RSA 4096 and SHA-512." To be sure that I am not making a fool of myself now, I just have checked all certificates again (openssl x509 -in <certificate_name>.crt -text -noout). I did that check not only with each certificate I have installed at my side, but also with the CA certificate and each certificate which is installed in the client's device. For each certificate, the output of the command mentioned above included the following lines (among others, leading spaces removed): Signature Algorithm: sha512WithRSAEncryption Public-Key: (4096 bit) So I think that your statement from your last post from yesterday is correct, and that there actually is more to the story. But what? Probably it is related to RFC 7427 ... Thank you very much, Binarus