Project

General

Profile

Issue #2514

X.509 signature scheme Validation Problem When more than one scheme is configured

Added by Jafar Al-Gharaibeh almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.6.0
Resolution:
No change required

Description

I want to enforce certificate signature of RSA-2048, ecdsa-256, or better. I followed the instructions for left|rightauth on:

https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection#leftright-End-Parameters

I did a copy-paste from the link above of:

"rsa-2048-ecdsa-256-sha256-sha384-sha512"

to rightauth in ipsec.conf file. I also have a certificate signed with an RSA-2048 key issued by an intimidate CA using a cert with RSA-2048 bit.

I get the following error when I bring the connection up it fails with the following log:

authentication of 'C=US, O=ATC, CN=mars' with
RSA_EMSA_PKCS1_SHA2_256 successful
X.509 signature scheme RSA_EMSA_PKCS1_SHA2_256 not acceptable.

I dropped the ecdsa-256 from my config and used only

"rsa-2048-sha256-sha384-sha512"

The connection succeeds and works just fine.

I also tried swapping the order of rsa and ecdsa in the config such that I have:

"ecdsa-256-rsa-2048-sha256-sha384-sha512"

with everything else being the same and the the connection succeeds and works.

I tried another cert with pubkey: ECDSA 233 bits

if I set rightauth to pubkey it works, but if I add "ecdsa" such as:

"ecdsa-256-sha256-sha384-sha512"
"ecdsa-233-sha256-sha384-sha512"
"ecdsa-128-sha256-sha384-sha512"
"ecdsa-128"

all failed.

Associated revisions

Revision e698bdea (diff)
Added by Tobias Brunner almost 4 years ago

man: Fix documentation of pubkey constraints

Hash algorithms have to be repeated for multiple key types.

References #2514.

History

#1 Updated by Tobias Brunner almost 4 years ago

  • Status changed from New to Feedback

That's due to how the parser for these constraints currently works. It expects a key type followed by the key size and then hash algorithm identifiers. If you want to allow multiple key types you have to repeat the hash algorithms after the second key type (or use pubkey, but then you can't limit the key size). For instance, rsa-2048-ecdsa-256-sha256-sha384-sha512 does not add any RSA signature schemes to the list as no hash algorithms immediately follow rsa-2048 (I noticed that the example given in the documentation was like this, but that's wrong). So to allow both key types you have to use rsa-2048-sha256-sha384-sha512-ecdsa-256-sha256-sha384-sha512.

#2 Updated by Jafar Al-Gharaibeh almost 4 years ago

Tobias Brunner wrote:

That's due to how the parser for these constraints currently works. It expects a key type followed by the key size and then hash algorithm identifiers. If you want to allow multiple key types you have to repeat the hash algorithms after the second key type (or use pubkey, but then you can't limit the key size). For instance, rsa-2048-ecdsa-256-sha256-sha384-sha512 does not add any RSA signature schemes to the list as no hash algorithms immediately follow rsa-2048 (I noticed that the example given in the documentation was like this, but that's wrong). So to allow both key types you have to use rsa-2048-sha256-sha384-sha512-ecdsa-256-sha256-sha384-sha512.

Thanks for looking at this. Yes, it was the example the threw me off, I noticed you have fixed it by dropping ecdsa. I will test the fixed syntax to use rsa/ecdsa. If that works I will add that as an example as well to the wiki page if you don't mind. It is helpful to see how it should be used.

Thanks Again!

#3 Updated by Jafar Al-Gharaibeh almost 4 years ago

I can confirm that the long form of concatenating constraints works fine, such as:

rsa-2048-sha256-sha384-sha512-ecdsa-256-sha256-sha384-sha512

I'm going to close this issue and update the wiki page with the example.

Thank You Tobias.

#4 Updated by Tobias Brunner almost 4 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

Thanks, made the example a bit shorter (I hope the principle is still clear) and added the same to the swanctl.conf docs.

Also available in: Atom PDF