Re: [strongSwan] no private key found with ECDSA certificate

2015-05-28 Thread Andreas Steffen

Hi Mark,

it usually is much easier to use the strongSwan pki tool to generate
ECDSA keys and certificates:

https://wiki.strongswan.org/projects/strongswan/wiki/IpsecPKI

Best regards

Andreas

On 27.05.2015 23:29, Mark M wrote:

Do you know this is an issue? it works fine on the Android device?



On Wednesday, May 27, 2015 5:25 PM, Mark M mark0...@yahoo.com wrote:


Noel,

I got it to work. I had to use ec instead of ecparam for the conversion
like this;

openssl ec -in /etc/pki/eccCA/centos2ecc.key -inform PEM -outform DER
-out centos2ecc.key

strongSwan can now load the private key and I can connect with my
Android client using ECDSA SHA384 certs :)

Thank you very much for the help.

Mark-




On Wednesday, May 27, 2015 5:18 PM, Mark M mark0...@yahoo.com wrote:


Not working,

I am using this method to convert, maybe it is wrong?

[root@CENTOS7 ~]# openssl ecparam -in /etc/pki/eccCA/centos2ecc.key
-inform PEM -outform DER -out centos2ecc.key


I am getting

00[LIB]   file coded in unknown format, discarded
00[LIB] building CRED_PRIVATE_KEY - ECDSA failed, tried 4 builders
00[CFG]   loading private key from
'/etc/strongswan/ipsec.d/private/centos2ecc.der' failed





On Wednesday, May 27, 2015 5:10 PM, Noel Kuntze n...@familie-kuntze.de
wrote:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Mark,

Try converting the key from PEM to DER format.

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 27.05.2015 um 23:03 schrieb Mark M:
  Noel,
 
   Here is a pastebin of the log with the settings you asked for -
 
  http://pastebin.com/4T47jNNA
 
  I am seeing this a problem
 
  1.
 00[CFG] loading secrets from '/etc/strongswan/ipsec.secrets'
  2.
 00[LIB] building CRED_PRIVATE_KEY - ECDSA failed, tried 4 builders
  3.
 00[CFG]  loading private key from
'/etc/strongswan/ipsec.d/private/centos2ecc.key' failed
 
 
 
 
  On Wednesday, May 27, 2015 4:32 PM, Noel Kuntze
n...@familie-kuntze.de mailto:n...@familie-kuntze.de wrote:
 
 
 
  Hello Mark,
 
  Okay, what does charon say during daemon startup?
  Please create a log witht the following settings and post it here.
  You are encouraged to use a pastebin service.
 
  default = 3
  mgr = 1
  ike = 1
  net = 1
  enc = 0
  cfg = 2
  asn = 1
  job = 1
  knl = 1
 
  Mit freundlichen Grüßen/Kind Regards,
  Noel Kuntze
 
  GPG Key ID: 0x63EC6658
  Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
 
  Am 27.05.2015 um 22:25 schrieb Mark M:
   Hi Noel,
 
   I did specify the key in ipsec.secrets. I am doing everything the
same way I did with RSA certificates that work fine. Here is my config
and how I generated the ECC keys and certs. I am thinking this is an
issue with how I genereated the ECC keys and certs?
 
 
   openssl ecparam -genkey -name secp384r1 -out centos2ecc.key
 
openssl req -new -key centos2ecc.key -out centos2ecc.csr -config
/etc/pki/newca/opensslc1.cnf -sha384
 
   openssl x509 -req -in centos2ecc.csr -CA rooteccCA.crt -CAkey
eccCA.key -CAcreateserial -out centos2ecc.crt -days 365 -extensions
v3_req -extfile /etc/pki/newca/opensslc1.cnf -sha384
 
   opensslc1.cnf file:
 
   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_req
 
   [req_distinguished_name]
   countryName = Country Name (2 letter code)
   stateOrProvinceName = State or Province Name (full name)
   localityName = Locality Name (eg, city)
   organizationalUnitName = Organizational Unit Name (eg, section)
   commonName =
 
   [v3_req]
   basicConstraints = CA:FALSE
   keyUsage = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName = @alt_names
 
   [alt_names]
   IP.1=10.X.X.X
   IP.2=192.168.1.7
   ~
 
   ipsec.secrets
 
   # /etc/ipsec.secrets - strongSwan IPsec secrets file
 
   : RSA centos2.key
   : ECDSA centos2ecc.key
 
 
 
   [root@CENTOS7 mailto:root@CENTOS7 mailto:root@CENTOS7
mailto:root@CENTOS7 ~]# vi /etc/strongswan/ipsec.conf
   #  leftsendcert=never
   #  right=192.168.0.2
   #  rightsubnet=10.2.0.0/16
   #  rightcert=peerCert.der
   #  auto=start
 
   #conn sample-with-ca-cert
   #  leftsubnet=10.1.0.0/16
   #  leftcert=myCert.pem
   #  right=192.168.0.2
   #  rightsubnet=10.2.0.0/16
   #  rightid=C=CH, O=Linux strongSwan CN=peer name
   #  auto=start
   conn %default
  keyexchange=ikev2
 
   conn phone1ecc
  left=%defaultroute
  leftcert=centos2ecc.crt
  leftsubnet=0.0.0.0/0
  leftid=C=US, ST=MA, L=SELF, O=SSCA, OU=SS, CN=192.168.1.7
  leftfirewall=yes
  right=%any
  rightsourceip=192.168.9.0/24
  esp=aes256-sha384-ecp384!
  ike=aes256-sha384-ecp384!
  auto=add
 
 
 
 
 
   On Wednesday, May 27, 2015 7:56 AM, Noel Kuntze
n...@familie-kuntze.de mailto:n...@familie-kuntze.de
mailto:n...@familie-kuntze.de mailto:n...@familie-kuntze.de wrote:
 
 
 
   Hello Mark,
 
   Well, did 

Re: [strongSwan] Failing to login due to constraint check failed

2015-05-28 Thread Martin Willi

 why it wasn't sending identity before but does sent it now?

The client now offers EAP authentication by omitting the AUTH payload in
the first IKE_AUTH exchange. This allows the server to trigger the
EAP-Identity exchange, followed by EAP-MSCHAPv2.

  and why does authentication fail?

The client rejects the EAP-MSCHAPv2 method with EAP-NAK. It is
configured to use something else or does not support it. AFAIK iOS
supports EAP-MSCHAPv2, so most likely this is a client configuration
issue.

Regards
Martin

___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users