[strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable

[Binarus]

Dear all,

I am getting the error message mentioned above when trying to connect to
a client's site. Of course, I have tried to research if there already
has been a similar problem, and have found exactly one appropriate thread:

https://lists.strongswan.org/pipermail/users/2018-March/012351.html

Unfortunately, my situation is different; in my case, something else
seems to cause the problem. Having said this:

- It happened after the upgrade from Debian jessie (Debian 8) to Debian
stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
StrongSwan 5.5.1)

- I definitely have copied the whole configuration (including
certificates and so on) from the old system to the new one (AFTER having
installed the new StrongSwan version in the new system). I have double
checked multiple times (applying different methods) that nothing is missing.

- With the old system, I definitely could connect to the client's site
without any problem with exact that configuration.

If it matters, the VPN Gateway at the client's side is a Lancom router
(I don't know the exact type, but it is newer one, and I am absolutely
sure that they didn't any changes to it while I was upgrading my system,
and to stress it again, the old system / StrongSwan version could
connect to that device without problems).

This is my /etc/ipsec.conf (sensitive data has been changed, and lines
which are commented out have been left away):


config setup

conn %default
mobike=no

conn myclient
ikelifetime=10800s
keylife=3600s
rekeymargin=9m
keyingtries=1
type=tunnel
keyexchange=ikev2
mobike=no
ike=aes256-sha512-modp4096!
esp=aes256-sha512-modp4096!
left=xxxxxxxxxxxxxxxx.hopto.org
leftauth=rsa-4096-sha512
leftid="/CN=xxxxxxxxxxxxxxxx.hopto.org"
leftsubnet=192.168.20.0/24
leftfirewall=no
leftcert=mycompany-client.crt
right=yyyyyyyyyyyyyyyy.zapto.org
rightauth=rsa-4096-sha512
rightid="/CN=yyyyyyyyyyyyyyyy.zapto.org"
rightsubnet=192.168.0.0/24
auto=add


This is the error message (sensitive data changed in the same way as
with ipsec.conf):

***@charon:/etc# /etc/init.d/ipsec restart
[ ok ] Restarting ipsec (via systemctl): ipsec.service.
***@charon:/etc# ipsec up myclient
initiating IKE_SA myclient[3] to 79.192.42.125
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (714 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (713 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
received 1 cert requests for an unknown ca
sending cert request for "CN=ca.clientsite.local"
authentication of 'CN=xxxxxxxxxxxxxxxx.hopto.org' (myself) with RSA
signature successful
sending end entity cert "CN=xxxxxxxxxxxxxxxx.hopto.org"
establishing CHILD_SA myclient
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr
AUTH SA TSi TSr N(EAP_ONLY) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (2048 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (1984 bytes)
parsed IKE_AUTH response 1 [ IDr CERT AUTH TSi TSr N(INIT_CONTACT) SA ]
received end entity cert "CN=yyyyyyyyyyyyyyyy.zapto.org"
using certificate "CN=yyyyyyyyyyyyyyyy.zapto.org"
using trusted ca certificate "CN=ca.clientsite.local"
checking certificate status of "CN=yyyyyyyyyyyyyyyy.zapto.org"
certificate status is not available
reached self-signed root ca with a path length of 0
authentication of 'CN=yyyyyyyyyyyyyyyy.zapto.org' with RSA signature
successful
IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
selected peer config 'myclient' inacceptable: constraint checking failed
no alternative config found
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (96 bytes)
establishing connection 'myclient' failed
***@charon:/etc#


Does anybody have an idea?

Thank you very much in advance,

Binarus

[Jafar Al-Gharaibeh]

Binarus,

    Obviously the client proposal doesn't match what your server expect
regardless of what you think has changed or not changed.
  To debug this better increase your logging level bu adding the
following under your config setup section:

charondebug="ike 3, net 3, mgr 3, esp 3, chd 3, dmn 3, cfg 3"

  That would allow you to see more information about the exchange.

--Jafar

Post by Binarus
Dear all,
I am getting the error message mentioned above when trying to connect to
a client's site. Of course, I have tried to research if there already
https://lists.strongswan.org/pipermail/users/2018-March/012351.html
Unfortunately, my situation is different; in my case, something else
- It happened after the upgrade from Debian jessie (Debian 8) to Debian
stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
StrongSwan 5.5.1)
- I definitely have copied the whole configuration (including
certificates and so on) from the old system to the new one (AFTER having
installed the new StrongSwan version in the new system). I have double
checked multiple times (applying different methods) that nothing is missing.
- With the old system, I definitely could connect to the client's site
without any problem with exact that configuration.
If it matters, the VPN Gateway at the client's side is a Lancom router
(I don't know the exact type, but it is newer one, and I am absolutely
sure that they didn't any changes to it while I was upgrading my system,
and to stress it again, the old system / StrongSwan version could
connect to that device without problems).
This is my /etc/ipsec.conf (sensitive data has been changed, and lines
config setup
conn %default
mobike=no
conn myclient
ikelifetime=10800s
keylife=3600s
rekeymargin=9m
keyingtries=1
type=tunnel
keyexchange=ikev2
mobike=no
ike=aes256-sha512-modp4096!
esp=aes256-sha512-modp4096!
left=xxxxxxxxxxxxxxxx.hopto.org
leftauth=rsa-4096-sha512
leftid="/CN=xxxxxxxxxxxxxxxx.hopto.org"
leftsubnet=192.168.20.0/24
leftfirewall=no
leftcert=mycompany-client.crt
right=yyyyyyyyyyyyyyyy.zapto.org
rightauth=rsa-4096-sha512
rightid="/CN=yyyyyyyyyyyyyyyy.zapto.org"
rightsubnet=192.168.0.0/24
auto=add
This is the error message (sensitive data changed in the same way as
[ ok ] Restarting ipsec (via systemctl): ipsec.service.
initiating IKE_SA myclient[3] to 79.192.42.125
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (714 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (713 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
received 1 cert requests for an unknown ca
sending cert request for "CN=ca.clientsite.local"
authentication of 'CN=xxxxxxxxxxxxxxxx.hopto.org' (myself) with RSA
signature successful
sending end entity cert "CN=xxxxxxxxxxxxxxxx.hopto.org"
establishing CHILD_SA myclient
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr
AUTH SA TSi TSr N(EAP_ONLY) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (2048 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (1984 bytes)
parsed IKE_AUTH response 1 [ IDr CERT AUTH TSi TSr N(INIT_CONTACT) SA ]
received end entity cert "CN=yyyyyyyyyyyyyyyy.zapto.org"
using certificate "CN=yyyyyyyyyyyyyyyy.zapto.org"
using trusted ca certificate "CN=ca.clientsite.local"
checking certificate status of "CN=yyyyyyyyyyyyyyyy.zapto.org"
certificate status is not available
reached self-signed root ca with a path length of 0
authentication of 'CN=yyyyyyyyyyyyyyyy.zapto.org' with RSA signature
successful
IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
selected peer config 'myclient' inacceptable: constraint checking failed
no alternative config found
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (96 bytes)
establishing connection 'myclient' failed
Does anybody have an idea?
Thank you very much in advance,
Binarus

[Binarus]

Jafar,

at first, thank you very much for taking the time; it is highly appreciated.

    Obviously the client proposal doesn't match what your server expect regardless of what you think has changed or not changed.
charondebug="ike 3, net 3, mgr 3, esp 3, chd 3, dmn 3, cfg 3"
  That would allow you to see more information about the exchange.

Thank you very much for that hint. I'll remember next time ...

However, since I was absolutely sure that nobody at my client's site had changed their router's configuration, I have done further research. Among others, I have studied my /etc/strongswan.d/charon.conf again and came across a setting which looked highly suspicious to me:

signature_authentication_constraints = yes

Entering "signature_authentication_constraints" into Google immediately lead to this article:

https://www.strongswan.org/blog/2015/03/30/strongswan-5.3.0-released.html

After having read the second section of that article, I turned off the setting mentioned above (i.e. set it to no), and now it works as before.

So it seems that the issue didn't have anything to do with non-matching proposals, but with that setting, which seems to have been introduced (or seems to have been assigned another default value) with version 5.3.0. This explains why my old configuration with the old version 5.2.1 worked, but the same configuration with the new version 5.5.1 didn't.

While my urgent and immediate problem is solved now, I still have a hard time actually understanding what that article section is talking about. I would be grateful if somebody could explain the issue for people who are not full-time professional cryptographers. Specifically, I have not fully understood the following sentences yet:

"Key types and hash algorithms specified in rightauth are now also checked against IKEv2 signature schemes. If such constraints are used for certificate chain validation in existing configurations, in particular with peers that don't support RFC 7427, it may be necessary to disable this feature with the charon.signature_authentication_constraints setting, because the signature scheme used in classic IKEv2 public key authentication may not be strong enough."

I believe I have configured the strongest rightauth and leftauth scheme the router at the client's site supports, which probably is the strongest scheme commonly used with RSA (at least, I haven't heard of SHA768 or SHA1024 yet, or that SHA3 or RSA8192 are currently being supported by more than a few exotic router / VPN devices). 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.

So what exactly does StrongSwan (charon) expect here (i.e. what would it consider strong enough), and how do I configure it (in case I decide to re-enable signature_authentication_constraints)? A simple explanation would be very nice; otherwise, probably we (I assume that I am not the only person who hasn't fully understood that section) will have to study RFC 7427, which we'd like to avoid :-).

Thank you very much in advance,

Binarus

--Jafar

Post by Binarus
Dear all,
I am getting the error message mentioned above when trying to connect to
a client's site. Of course, I have tried to research if there already
https://lists.strongswan.org/pipermail/users/2018-March/012351.html
Unfortunately, my situation is different; in my case, something else
- It happened after the upgrade from Debian jessie (Debian 8) to Debian
stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
StrongSwan 5.5.1)
- I definitely have copied the whole configuration (including
certificates and so on) from the old system to the new one (AFTER having
installed the new StrongSwan version in the new system). I have double
checked multiple times (applying different methods) that nothing is missing.
- With the old system, I definitely could connect to the client's site
without any problem with exact that configuration.
If it matters, the VPN Gateway at the client's side is a Lancom router
(I don't know the exact type, but it is newer one, and I am absolutely
sure that they didn't any changes to it while I was upgrading my system,
and to stress it again, the old system / StrongSwan version could
connect to that device without problems).
This is my /etc/ipsec.conf (sensitive data has been changed, and lines
config setup
conn %default
   mobike=no
conn myclient
   ikelifetime=10800s
   keylife=3600s
   rekeymargin=9m
   keyingtries=1
   type=tunnel
   keyexchange=ikev2
   mobike=no
   ike=aes256-sha512-modp4096!
   esp=aes256-sha512-modp4096!
   left=xxxxxxxxxxxxxxxx.hopto.org
   leftauth=rsa-4096-sha512
   leftid="/CN=xxxxxxxxxxxxxxxx.hopto.org"
   leftsubnet=192.168.20.0/24
   leftfirewall=no
   leftcert=mycompany-client.crt
   right=yyyyyyyyyyyyyyyy.zapto.org
   rightauth=rsa-4096-sha512
   rightid="/CN=yyyyyyyyyyyyyyyy.zapto.org"
   rightsubnet=192.168.0.0/24
   auto=add
This is the error message (sensitive data changed in the same way as
[ ok ] Restarting ipsec (via systemctl): ipsec.service.
initiating IKE_SA myclient[3] to 79.192.42.125
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (714 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (713 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
received 1 cert requests for an unknown ca
sending cert request for "CN=ca.clientsite.local"
authentication of 'CN=xxxxxxxxxxxxxxxx.hopto.org' (myself) with RSA
signature successful
sending end entity cert "CN=xxxxxxxxxxxxxxxx.hopto.org"
establishing CHILD_SA myclient
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr
AUTH SA TSi TSr N(EAP_ONLY) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (2048 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (1984 bytes)
parsed IKE_AUTH response 1 [ IDr CERT AUTH TSi TSr N(INIT_CONTACT) SA ]
received end entity cert "CN=yyyyyyyyyyyyyyyy.zapto.org"
   using certificate "CN=yyyyyyyyyyyyyyyy.zapto.org"
   using trusted ca certificate "CN=ca.clientsite.local"
checking certificate status of "CN=yyyyyyyyyyyyyyyy.zapto.org"
certificate status is not available
   reached self-signed root ca with a path length of 0
authentication of 'CN=yyyyyyyyyyyyyyyy.zapto.org' with RSA signature
successful
IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
selected peer config 'myclient' inacceptable: constraint checking failed
no alternative config found
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (96 bytes)
establishing connection 'myclient' failed
Does anybody have an idea?
Thank you very much in advance,
Binarus

[Jafar Al-Gharaibeh]

Post by Binarus
signature_authentication_constraints = yes
https://www.strongswan.org/blog/2015/03/30/strongswan-5.3.0-released.html
After having read the second section of that article, I turned off the setting mentioned above (i.e. set it to no), and now it works as before.
So it seems that the issue didn't have anything to do with non-matching proposals, but with that setting, which seems to have been introduced (or seems to have been assigned another default value) with version 5.3.0. This explains why my old configuration with the old version 5.2.1 worked, but the same configuration with the new version 5.5.1 didn't.

  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].

Regards,
Jafar


[1] https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

Post by Binarus
"Key types and hash algorithms specified in rightauth are now also checked against IKEv2 signature schemes. If such constraints are used for certificate chain validation in existing configurations, in particular with peers that don't support RFC 7427, it may be necessary to disable this feature with the charon.signature_authentication_constraints setting, because the signature scheme used in classic IKEv2 public key authentication may not be strong enough."
I believe I have configured the strongest rightauth and leftauth scheme the router at the client's site supports, which probably is the strongest scheme commonly used with RSA (at least, I haven't heard of SHA768 or SHA1024 yet, or that SHA3 or RSA8192 are currently being supported by more than a few exotic router / VPN devices). 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.
So what exactly does StrongSwan (charon) expect here (i.e. what would it consider strong enough), and how do I configure it (in case I decide to re-enable signature_authentication_constraints)? A simple explanation would be very nice; otherwise, probably we (I assume that I am not the only person who hasn't fully understood that section) will have to study RFC 7427, which we'd like to avoid :-).
Thank you very much in advance,
Binarus

Post by Jafar Al-Gharaibeh
--Jafar

Post by Binarus
Dear all,
I am getting the error message mentioned above when trying to connect to
a client's site. Of course, I have tried to research if there already
https://lists.strongswan.org/pipermail/users/2018-March/012351.html
Unfortunately, my situation is different; in my case, something else
- It happened after the upgrade from Debian jessie (Debian 8) to Debian
stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
StrongSwan 5.5.1)
- I definitely have copied the whole configuration (including
certificates and so on) from the old system to the new one (AFTER having
installed the new StrongSwan version in the new system). I have double
checked multiple times (applying different methods) that nothing is missing.
- With the old system, I definitely could connect to the client's site
without any problem with exact that configuration.
If it matters, the VPN Gateway at the client's side is a Lancom router
(I don't know the exact type, but it is newer one, and I am absolutely
sure that they didn't any changes to it while I was upgrading my system,
and to stress it again, the old system / StrongSwan version could
connect to that device without problems).
This is my /etc/ipsec.conf (sensitive data has been changed, and lines
config setup
conn %default
   mobike=no
conn myclient
   ikelifetime=10800s
   keylife=3600s
   rekeymargin=9m
   keyingtries=1
   type=tunnel
   keyexchange=ikev2
   mobike=no
   ike=aes256-sha512-modp4096!
   esp=aes256-sha512-modp4096!
   left=xxxxxxxxxxxxxxxx.hopto.org
   leftauth=rsa-4096-sha512
   leftid="/CN=xxxxxxxxxxxxxxxx.hopto.org"
   leftsubnet=192.168.20.0/24
   leftfirewall=no
   leftcert=mycompany-client.crt
   right=yyyyyyyyyyyyyyyy.zapto.org
   rightauth=rsa-4096-sha512
   rightid="/CN=yyyyyyyyyyyyyyyy.zapto.org"
   rightsubnet=192.168.0.0/24
   auto=add
This is the error message (sensitive data changed in the same way as
[ ok ] Restarting ipsec (via systemctl): ipsec.service.
initiating IKE_SA myclient[3] to 79.192.42.125
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (714 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (713 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
received 1 cert requests for an unknown ca
sending cert request for "CN=ca.clientsite.local"
authentication of 'CN=xxxxxxxxxxxxxxxx.hopto.org' (myself) with RSA
signature successful
sending end entity cert "CN=xxxxxxxxxxxxxxxx.hopto.org"
establishing CHILD_SA myclient
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr
AUTH SA TSi TSr N(EAP_ONLY) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (2048 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (1984 bytes)
parsed IKE_AUTH response 1 [ IDr CERT AUTH TSi TSr N(INIT_CONTACT) SA ]
received end entity cert "CN=yyyyyyyyyyyyyyyy.zapto.org"
   using certificate "CN=yyyyyyyyyyyyyyyy.zapto.org"
   using trusted ca certificate "CN=ca.clientsite.local"
checking certificate status of "CN=yyyyyyyyyyyyyyyy.zapto.org"
certificate status is not available
   reached self-signed root ca with a path length of 0
authentication of 'CN=yyyyyyyyyyyyyyyy.zapto.org' with RSA signature
successful
IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
selected peer config 'myclient' inacceptable: constraint checking failed
no alternative config found
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (96 bytes)
establishing connection 'myclient' failed
Does anybody have an idea?
Thank you very much in advance,
Binarus

[Jafar Al-Gharaibeh]

Binarus, BTW, that was my quick assessment, so there might be more to
the story :-).

--Jafar

Post by Jafar Al-Gharaibeh

Post by Binarus
However, since I was absolutely sure that nobody at my client's site
had changed their router's configuration, I have done further
research. Among others, I have studied my
/etc/strongswan.d/charon.conf again and came across a setting which
signature_authentication_constraints = yes
Entering "signature_authentication_constraints" into Google
https://www.strongswan.org/blog/2015/03/30/strongswan-5.3.0-released.html
After having read the second section of that article, I turned off the
setting mentioned above (i.e. set it to no), and now it works as
before.
So it seems that the issue didn't have anything to do with
non-matching proposals, but with that setting, which seems to have
been introduced (or seems to have been assigned another default value)
with version 5.3.0. This explains why my old configuration with the
old version 5.2.1 worked, but the same configuration with the new
version 5.5.1 didn't.

  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
   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].
Regards,
Jafar
[1] https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

Post by Binarus
While my urgent and immediate problem is solved now, I still have a
hard time actually understanding what that article section is talking
about. I would be grateful if somebody could explain the issue for
people who are not full-time professional cryptographers.
"Key types and hash algorithms specified in rightauth are now also
checked against IKEv2 signature schemes. If such constraints are used
for certificate chain validation in existing configurations, in
particular with peers that don't support RFC 7427, it may be necessary
to disable this feature with the
charon.signature_authentication_constraints setting, because the
signature scheme used in classic IKEv2 public key authentication may
not be strong enough."
I believe I have configured the strongest rightauth and leftauth
scheme the router at the client's site supports, which probably is the
strongest scheme commonly used with RSA (at least, I haven't heard of
SHA768 or SHA1024 yet, or that SHA3 or RSA8192 are currently being
supported by more than a few exotic router / VPN devices).
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.
So what exactly does StrongSwan (charon) expect here (i.e. what would
it consider strong enough), and how do I configure it (in case I
decide to re-enable signature_authentication_constraints)? A simple
explanation would be very nice; otherwise, probably we (I assume that
I am not the only person who hasn't fully understood that section)
will have to study RFC 7427, which we'd like to avoid :-).
Thank you very much in advance,
Binarus

Post by Jafar Al-Gharaibeh
--Jafar

Post by Binarus
Dear all,
I am getting the error message mentioned above when trying to connect to
a client's site. Of course, I have tried to research if there already
https://lists.strongswan.org/pipermail/users/2018-March/012351.html
Unfortunately, my situation is different; in my case, something else
- It happened after the upgrade from Debian jessie (Debian 8) to Debian
stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
StrongSwan 5.5.1)
- I definitely have copied the whole configuration (including
certificates and so on) from the old system to the new one (AFTER having
installed the new StrongSwan version in the new system). I have double
checked multiple times (applying different methods) that nothing is missing.
- With the old system, I definitely could connect to the client's site
without any problem with exact that configuration.
If it matters, the VPN Gateway at the client's side is a Lancom router
(I don't know the exact type, but it is newer one, and I am
absolutely
sure that they didn't any changes to it while I was upgrading my system,
and to stress it again, the old system / StrongSwan version could
connect to that device without problems).
This is my /etc/ipsec.conf (sensitive data has been changed, and lines
config setup
conn %default
   mobike=no
conn myclient
   ikelifetime=10800s
   keylife=3600s
   rekeymargin=9m
   keyingtries=1
   type=tunnel
   keyexchange=ikev2
   mobike=no
   ike=aes256-sha512-modp4096!
   esp=aes256-sha512-modp4096!
   left=xxxxxxxxxxxxxxxx.hopto.org
   leftauth=rsa-4096-sha512
   leftid="/CN=xxxxxxxxxxxxxxxx.hopto.org"
   leftsubnet=192.168.20.0/24
   leftfirewall=no
   leftcert=mycompany-client.crt
   right=yyyyyyyyyyyyyyyy.zapto.org
   rightauth=rsa-4096-sha512
   rightid="/CN=yyyyyyyyyyyyyyyy.zapto.org"
   rightsubnet=192.168.0.0/24
   auto=add
This is the error message (sensitive data changed in the same way as
[ ok ] Restarting ipsec (via systemctl): ipsec.service.
initiating IKE_SA myclient[3] to 79.192.42.125
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP)
N(NATD_D_IP)
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (714 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (713 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
received 1 cert requests for an unknown ca
sending cert request for "CN=ca.clientsite.local"
authentication of 'CN=xxxxxxxxxxxxxxxx.hopto.org' (myself) with RSA
signature successful
sending end entity cert "CN=xxxxxxxxxxxxxxxx.hopto.org"
establishing CHILD_SA myclient
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr
AUTH SA TSi TSr N(EAP_ONLY) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (2048 bytes)
received packet: from 79.192.42.125[500] to 87.185.83.87[500] (1984 bytes)
parsed IKE_AUTH response 1 [ IDr CERT AUTH TSi TSr N(INIT_CONTACT) SA ]
received end entity cert "CN=yyyyyyyyyyyyyyyy.zapto.org"
   using certificate "CN=yyyyyyyyyyyyyyyy.zapto.org"
   using trusted ca certificate "CN=ca.clientsite.local"
checking certificate status of "CN=yyyyyyyyyyyyyyyy.zapto.org"
certificate status is not available
   reached self-signed root ca with a path length of 0
authentication of 'CN=yyyyyyyyyyyyyyyy.zapto.org' with RSA signature
successful
IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
selected peer config 'myclient' inacceptable: constraint checking failed
no alternative config found
generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (96 bytes)
establishing connection 'myclient' failed
Does anybody have an idea?
Thank you very much in advance,
Binarus

[Binarus]

Jafar,

thank you very much again.

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

[Jafar Al-Gharaibeh]

Binarus,

    Did you manage to increase the logging level and get more
information? That would be helpful in determining what is going on.

  --Jafar

Post by Binarus
Jafar,
thank you very much again.

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
   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
"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
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

[Binarus]

Jafar,

Post by Jafar Al-Gharaibeh
    Did you manage to increase the logging level and get more
information? That would be helpful in determining what is going on.

I did not try yet because my urgent and immediate problem has been
solved by turning off the respective option as advised in the article
mentioned in my previous posts.

Right now, I don't have the time to investigate this issue further. I
still hope that there is a sympathetic member in the StrongSwan
development who could answer the questions from my previous posts.

After all, it's holiday time; perhaps we'll get an answer when everybody
is back to work. If not, I'll try to understand that RFC, but I have to
put this on hold until I have some spare time ...

Regards, and thanks again,

Binarus