Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
Jafar, On 22.08.2018 16:50, Jafar Al-Gharaibeh wrote: > 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
[strongSwan] Certificates
We use LetsEncrypt certs that need renewing every 90 days. I guess the process for StrongSwan is to just replace the current certificate and reload. But doesnt this keep the old certificate in cache? What if we renew early and then there are two valid certificates in cache?
[strongSwan] Problems with CRLs
Hello!
We are experiencing two problems when using CRLs.
Our Linux systems runs strongSwan 5.6.2.
1) Because we want a hourly update of CRLs and the standard CRLs timeout
is 7 days, we created a cronjob, that fetches the latest CRL every hour.
This CRL file is named:
/etc/ipsec.d/crls/COMPANY-SUB-CA01.crl
For a test, I additionally enabled CRL caching, but this did not
make any difference:
charon {
cache_crls = yes
}
Here is the problematic run:
Aug 22 16:54:44 2101120420063 charon: 15510[CFG] rereading crls from
'/etc/ipsec.d/crls'
Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
'/etc/ipsec.d/crls/0dff165cefbd2ddfb18f27e9215a4897b79f3008.crl'
Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #75 is not newer -
existing crl #75 retained
Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
'/etc/ipsec.d/crls/2d07eba139f0caad8a5ef7b87d542c46bbcd48ab.crl'
Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #02 is not newer -
existing crl #02 retained
Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
'/etc/ipsec.d/crls/48db6c1436fcdce1dc14b91619344b669e4dee6c.crl'
Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #01:62:32 is not newer
- existing crl #01:62:32 retained
Aug 22 16:54:44 2101120420063 charon: 15510[CFG] loaded crl from
'/etc/ipsec.d/crls/COMPANY-SUB-CA01.crl'
Aug 22 16:54:44 2101120420063 charon: 15510[LIB] crl #77 is newer -
existing crl #75 replaced
As you can see here, the manually updated CRL is newer (#77) and strongSwan
replaces the old one (#75) by this new version. This seems to be correct.
In the new (#77) CRL I have the following entry:
Serial Number: 250075E60D6340C615C22D00010075
Revocation Date: Aug 22 16:49:00 2018 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Certificate Hold
Now, if I try to connect, I get the following output and the user is accepted.
But this is wrong, because the certificate is on hold!
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl is valid: until Aug 30
04:58:47 2018
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using cached crl
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] fetching crl from
'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl' ...
Aug 22 16:54:53 2101120420063 charon: 15504[LIB] sending request to
'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl'...
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] fetching crl from
'http://ca.COMPANY.net/CertEnroll/COMPANY-SUB-CA01+.crl' ...
Aug 22 16:54:53 2101120420063 charon: 15504[LIB] sending request to
'http://ca.COMPANY.net/CertEnroll/COMPANY-SUB-CA01+.crl'...
Aug 22 16:54:53 2101120420063 charon: 15504[LIB] libcurl request failed [60]:
SSL certificate problem, verify that the CA cert is OK. Details:
Aug 22 16:54:53 2101120420063 charon: 15504[LIB] error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl fetching failed
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate status is good
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate "DC=local,
DC=company-group, CN=COMPANY-SUB-CA01" key: 4096 bit RSA
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using trusted ca
certificate "CN=COMPANY-ROOT-CA01"
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] checking certificate status
of "DC=local, DC=company-group, CN=COMPANY-SUB-CA01"
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] ocsp check skipped, no ocsp
found
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using trusted certificate
"CN=COMPANY-ROOT-CA01"
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl correctly signed by
"CN=COMPANY-ROOT-CA01"
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] crl is valid: until Jun 05
21:52:45 2028
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] using cached crl
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate status is good
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] certificate
"CN=COMPANY-ROOT-CA01" key: 4096 bit RSA
Aug 22 16:54:53 2101120420063 charon: 15504[CFG] reached self-signed root
ca with a path length of 1
Aug 22 16:54:53 2101120420063 charon: 15504[IKE] authentication of
'testu...@company.de' with RSA signature successful
If I restart strongSwan the user is denied correctly:
certificate was revoked on Aug 22 16:52:00 UTC 2018, reason: certificate hold
Where is my fault and can somebody explain it?
2) And we have another problem with delta CRLs:
As I understand strongSwan is supporting delta CRLs. The following line in the
logfile
shows, that strongSwan correctly fetches the (delta) CRL:
Aug 22 16:00:53 2101120420063 charon: 30400[CFG] fetching crl from
'http://ca.company-group.local/CertEnroll/COMPANY-SUB-CA01+.crl' ...
And the delta CRL has an entry with reason "remo
Re: [strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
Binarus, Did you manage to increase the logging level and get more information? That would be helpful in determining what is going on. --Jafar On 08/21/2018 01:11 AM, Binarus wrote: 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 .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
