[strongSwan] How to use Strongswan 5.0.1 & Smartcard correctly?

[richter at ecos.de]

HI Martin,

finally I got the time to test your latest patches (actually I test git master HEAD) regarding smartcards.

 It worked for me, but I need the changes I described in my earlier mails. Because this seems special to the smartcards I am using and I didn't found another solution, I add two config settings that allows to change the behavior as desired.

In pkcs11 config:

use_x509 = false 

Use the public key from the x509 certificate instead of the public key with the same ID to find the correct private key. This might be necessary for some smartcards, when the private key cannot be found during  connection setup.

require_x509 = true

When searching for the certificate on the smartcard, strongswan normaly searches for a certificate which is tagged as X509. If a certificate that is availbale on the card cannot be found, it might help to set this to false.

Patch is attached

Gerald


> -----Original Message-----
> From: Martin Willi [mailto:martin at strongswan.org]
> Sent: Wednesday, October 24, 2012 11:32 AM
> To: Gerald Richter - ECOS
> Cc: users at lists.strongswan.org
> Subject: RE: [strongSwan] How to use Strongswan 5.0.1 & Smartcard
> correctly?
> 
> Hi Gerald,
> 
> > a.) Increase max cert req payloads to 20 (this is not smartcard
> > related, but necessary for me because I have 6 ca certs in
> > etc/cacerts)
> 
> Yes, seems to make sense for IKEv1, as we have a CERTREQ for each CA.
> 
> > b.) Increase max length of pubkey id from 63 to 127 (the eToken has an
> > id longer than 63 chars)
> 
> I pushed [1] that doubles the buffer sizes.
> 
> > c.) In find_lib_by_keyid also fallback to use pubkey from cert, so I
> > can use %smartcard:<keyed> in ipsec.secrets without module and slot
> 
> I pushes a slightly different patch [2] that looks for a public key on all tokens
> first (current behavior), and then for a certificate. Let me know if this works
> for you.
> 
> > d.) find_pubkey_in_certs does not work for me if type is set to
> > CKC_X_509
> 
> I think it's not unproblematic, because a token with non-X509 certs could
> break that lookup.
> 
> According to PKCS#11, CKO_CERTIFICATE object MUST have a
> CKA_CERTIFICATE_TYPE set when created with C_CreateObject (PKCS#11
> 2.30, 10.6.2), hence I don't change the current behavior for now.
> 
> > There is only one current_type which is set to  AUTH_RULE_CA_CERT so
> > never matches the above condition.
> 
> There really should be a AUTH_RULE_SUBJECT_CERT when you define
> leftcert. Either this lookup happens on the wrong config, or something else is
> wrong.
> 
> Regards
> Martin
> 
> [1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=334eca9b
> [2]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=9b25d7c8

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pkcs11_privkey.patch
Type: application/octet-stream
Size: 2002 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20121115/7bd0d478/attachment.obj>