Found some time to look at this again, was working with
opensc 0.11.9 last days in my setup here.
On Thu, Feb 04, 2010 at 11:23:20AM +0100, Andreas Jellinghaus wrote:
> Am Donnerstag 04 Februar 2010 10:20:37 schrieb Christian Horn:
>
> > Also the nonworking opensc-rev hands out my personalized cert when
> > asking for id 46 with
> > pkcs15-tool -r 46|openssl x509 -noout -subject
>
> you have two certificates with id 46.
> which one is presented to you?
The one with my name in the subject, so the personalized one.
> or are two certificates shown with old opensc?
Output of 'pkcs15-tool -c' is the same with working/nonworking
opensc.
> does "opensc-tool -f" show the content of all files, including
> the certificates (file id in the pkcs15-tool --dump).
Yes, shows both df0143b1 (the cert i want) and df01c200 (the cert
that is now handed out by strongswan).
> or can you try downloading those certificate files with
> opensc-explorer? ("cd" to the directory (first 4 bytes),
> then "get" the file (the next four bytes of the pathname)).
> ("cd 3f00" gets you to the main folder / top directory...)
I can get both certs that way, and bot working/nonworking opensc
give me the same contents.
> first I guess strongswan wants to authenticate to the remote.
Yes.
> why does it try to use a CKA_ID 46 cert which is for encryption?
> strange. but maybe that certificate was placed on the remote site
> for some reason.
certid 46 is what i configured, its what i need to authenticate
with. The remote site apparently also checks the subject of the
cert that is used.
> > This is a personoalization-procedure done for the cards here.
>
> so your software for some reason created two certs with the same
> ID and now opensc need to sort out the mess :)
Yes, at a time in the past also pkcs15-tool did hand out the other
cert. By that time we patched opensc, later the code here was
changed to the other cert was handed out - and this is still the
behaviour of pkcs15-tool: pkcs15-tool -r 46 hands me out the cert
i really want, the personalized one.
> > Correct sig of the wrong cert i suspect..
>
> well, signatures are created with rsa keys, not certificates.
> and there is only one rsa key with ID 45, so it has to be the
> right one.
I think the cert is also checked on the remote side of the
vpn-connection here.
> can your somehow find all certificates, find out which is the
> right one, and which is the wrong one, and check if strongswan
> delivers the right or wrong file to the other side? maybe it
> shows the old certificate and then gets a signature with the
> RSA key (which is meant for the new certificate)?
Doing 'ipsec listcards' in strongswan gives me different results
with working/nonworking opensc:
working one shows my name in subject, nonworking one shows
subject: 'C=DE, ND=1, CN=NKS 08 A 78205', both for id 46.
> oh, and does the remote strongswan site show any errors
> that might show what is going on? again, I think it might
> be a strongswan issue...
Some proprietary stuff on the other side, hard to reach responsable
people there for debugging..
> btw: does the old and new ID 46 certificate contain the same
> rsa public key or do they differ? this would be interesting
> to know, if you can get to those files somehow.
No clue how to see this, just see 'id 46' as the link to what
rsa-key is to be used - and thats id 46 for both certs.
> > In the beginning also 'pkcs15-tool' spit out the other cert, we
> > started to fix this with internal patches, later it was properly
> > fixed in opensc-code.
>
> so worst case you can dig out an old version of opensc, to see
> what the old certificates are about?
I dont know what you mean by that. I noticed editing the paths to
the certs in pkcs15-tcos.c doesnt help me this time as it did in
the really old time bevore opensc was modified to hand out the
personalized cert when id 46 is requested.
> this whole situation with two certificates with the same ID
> confuses me a lot.
>
> maybe it is simple and some flag is used to disable the old ones,
> but I'm no expert here (and the asn.1 debugging code doesn't show
> values, so even if I knew what to look for, it wouldn't be in the
> log).
Would rather guess that the windows-software here is just coded
in such a way to deal with this.
Its also using a 'global pin' for everything instead of local ones.
> so maybe peter or pierre can help.
> other than that, I think it might be a strongswan issue.
> or at least getting the error from strongswan could help,
So any other ideas how pkcs11 could again perform with the
old behaviour?
> btw: you could extract the value to be signed and the signed
> data from the log file, transform them to binary, and check
> with your certificate (the one you can extract, or both),
> if that is a valid signature for the public key in the
> cert (IIRC openssl command line tools can extract it
> and/or use the cert or pubkey for signature validation).
Thanks for the idea.. guess if noone else here has an idea i
will approach strongswan list..
Christian
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
