-
I'll leave it to you to find out what's wrong with the stringification... hopefully the core dump can help you with that.
2009-06-15 20:32:04 UTC in GlobalPlatform
-
Okay. That answers my question about what's wrong, then. If the key is wrong, then I guess they changed it, since it's a retail card.
It makes sense, right? If someone knows the issuer domain key, then they can make the card do anything, including give up private keys, so a retail card provider would probably want to change the key before shipping it out.
Or am I mistaken about that?.
2009-06-15 20:31:05 UTC in GlobalPlatform
-
I put in a card I used less than this one, and put the original card I've been using in a different drawer.. I won't mess with it unless we figure this problem out. Attempt made with debugging variables. Log:
----
14/06 22:14:20 +establish_context in GlobalPlatform.c at line 521 : start
14/06 22:14:20 -establish_context in GlobalPlatform.c at line 531 : end RV(0x0)
14/06 22:14:20...
2009-06-15 02:17:42 UTC in GlobalPlatform
-
Oh.. unless you're saying I have 3 more tries on that *particular card* and you can tell from the output, and a card normally has many more than 3 tries?.
2009-06-15 02:06:59 UTC in GlobalPlatform
-
*sigh* Then I've likely destroied all five of the cards I bought.
I didn't know that this type of thing could irreversably damage the card.
In fact, I don't even know whether the keys I'm using are actually the right keys for the card. I just saw that same key used for a bunch of other cards. I have no idea if the retailer that supplied me with these cards uses the same key or what...
2009-06-15 02:00:18 UTC in GlobalPlatform
-
I've e-mailed you the core dump.
Also, does the output I supplied above give no indication at all of whether it's actually a JavaCard, and what may have caused the segfault?.
2009-06-14 19:48:14 UTC in GlobalPlatform
-
Hi, I recently bought some 'Aladdin eToken 64k SmartCard' cards and they turned out to not be the CardOS M4.2 I expected. I believe that they're java cards, so I tried using your gpshell-1.4.2 with globalplatform-5.0.0 to install 'MUSCLE' on them. I can't seem to get past the open_sc part. I tried to attach a core dump to this bug, but it wouldn't let me, and it made me type all this over...
2009-06-13 18:50:41 UTC in GlobalPlatform
-
It's my understanding that openssl can be asked to check the validity of a certificate based on configured root certificate files.
Assuming that trebuchet uses openssl's facilities to check its certs (i.e. it doesn't have built in certs like firefox), you just need to update your root certificates to something more recent. Startssl is pretty new, in terms of being a trusted CA.
Under gentoo...
2009-05-27 23:51:08 UTC in Fuzzball MUCK
-
Hi. There's a spiffy certificate authority out there that gives out free class 1 certificates. startssl.com
They're trusted by mozilla/firefox as a legitimate root CA authority (if your certs are up to date. Not yet with Microsoft)
So now I'm able to (and I have) signed the certificate for my MUCK at telnets://latitude.muck.ca:992
I'm not sure if tinyfugue can do this already or not...
2009-05-26 20:54:42 UTC in TinyFugue - MUD client
-
I figured it out. This function call:
SSL_CTX_use_certificate_file (ssl_ctx, SSL_CERT_FILE, SSL_FILETYPE_PEM)
If you use this instead, you can put the certificate chain inside the same server.pem file:
SSL_CTX_use_certificate_chain_file (ssl_ctx, SSL_CERT_FILE)
My MUCK is now valid and trusted ^.^ Assuming your certs are up to date.
2009-05-26 20:48:50 UTC in Fuzzball MUCK
