Topic: GLBSE's latest updates (an early Christmas present for non-techies) (Read 24071 times)

Ahh, sorry, well it doesn't seem to change much. If anything it looks a bit easier. There is a http rewrite module for nginx

The most robust rule that applies is probably something like this

The wiki says using try files are a good idea, so you might need to look into that if you want better scalability. HTH. Hopefully I didn't miss any other obvious information you've already stated.

Using nginx

I've dealt with redirects that were similar in complexity. it shouldn't be too hard if you are using apache, you just need to use the rewrite engine in the .htaccess file, i think.

using google I would say you'd want something like this. just for reference i altered the following example which seemed to be close enough to be workable

Yeah the www. redirect is a pain in the ASS.

My http server redirects all http traffic to https first, need to add www. to be redirected to non www before it does a https redirect.

I tried just doing the redirect as a cname in dns but hasn't worked.

as I mentioned earlier in the thread I'm certain it is just the twitter feed, at least with respect to firefox. it's pretty low priority in any case. having a redirect for the www sub-domain to primary domain would be a smidgeon higher on the list for trivial issues.

I'm using nginx as a ssl frontend and have different servers behind(none of them doing ssl). The main purpose of having ssl is to protect peoples glbse forums passwords (please if you have a forum account have a unique password, don' reuse passwords).

GLBSE clients (both web and command line) send no useful or itentiffying information so there is no need for ssl for that, actually the entire server database could be stolen and it would still provide no more information than a bunch of transaction records, some bitcoin addresses and a big list of public keys. OK I'd like for all that information to stay private but still, thats your limit of personal data exposure when using GLBSE.

We dont keep emails or anything else. Oh we do keep access logs, i.e. so we can debug any problems and normal http logs.

With regards the Chrome warning, thats because we've got links to non-ssl resources on the home page (the feedback form for example, possibly even the twitter feed stuff).

Ben, you can go ahead and not worry about verification of the ssl cert for development ATM, I'll get that fixed by Friday (god I hate ssl certs).

Something which does puzzle me still is the chain presented to web browsers (I've checked with Chrome and Firefox) is as follows ...

server certificate ...
Subject : CN = glbse.com, OU = Domain Control Validated - RapidSSL(R), OU = See www.rapidssl.com/resources/cps (c)11, OU = GT03597358, O = glbse.com, C = IE, serialNumber = ihbeLvU08wDc8R9L8WnCx/p8NSlr31ij
Issuer : CN = RapidSSL CA, O = GeoTrust, Inc., C = US

intermediate certificate ...
Subject : CN = RapidSSL CA, O = GeoTrust, Inc., C = US
Issuer : CN = GeoTrust Global CA, O = GeoTrust Inc., C = US

root certificate ...
Subject : CN = GeoTrust Global CA, O = GeoTrust Inc., C = US
Issuer : CN = GeoTrust Global CA, O = GeoTrust Inc., C = US

... and that appears trusted by them. However, that isn't the chain presented to openssl and gnutls - is this because they are negotiating differently from the browsers ?


I note that the chains presented to web browsers for https://encrypted.google.com and https://login.yahoo.com matches the chains presented to openssl and gnutls. Weird.

Seconded.

One step at a time ;O)

I think it is just the twitter feed which is unsecured. Should just be a case of replacing the http://search.twitter.com URLs with https://search.twitter.com

Link to the Market Charts might also be a problem. I'd need access to the server itself to test.

The web client is fine for humans, but I am developing applications to extend GLBSE functionality and utilise it as a backend for other services - so verification that those applications are really talking to the server they expect to be is very important.

Except for the warning (in Chrome) that "Your connection to glbse.com is encrypted with 256-bit encryption. However, this page includes other resources which are not secure. These resources can be viewed by others while in transit, and can be modified by an attacker to change the behavior of the page."

The certificate is OK, though.

Ben Walsh (beamer) better use web client.

I went checking on RapidSSL site for the relevant intermediate CA certificate and found an "installation checker" ... https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&id=SO9556

If you test glbse.com with that "installation checker", it confirms there is an invalid chain and details what resolution is required - you actually just need to replace your current intermediate certificate 1 with the one they provide in the report.



Download the required certificate from here - https://knowledge.rapidssl.com/library/VERISIGN/ALL_OTHER/David%20A./Rapidssl/Secondary%20Intermediate.txt

I had problems just copying and pasting from that text box of the "installation checker".

Your chain will then be ...

server certificate ...
subject `serialNumber=ihbeLvU08wDc8R9L8WnCx/p8NSlr31ij,C=IE,O=glbse.com,OU=GT03597358,OU=See www.rapidssl.com/resources/cps (c)11,OU=Domain Control Validated - RapidSSL(R),CN=glbse.com'
issuer `C=US,O=GeoTrust\, Inc.,CN=RapidSSL CA'

intermediate certificate 1 ...
subject `C=US,O=GeoTrust\, Inc.,CN=RapidSSL CA'
issuer `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA'

intermediate certificate 2 ...
subject `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA'
issuer `C=US,O=Equifax,OU=Equifax Secure Certificate Authority'


Give me a yell once you've done that and I test it out for you.

Or Yahoo, with a longer chain ...


ben@ben-laptop2:~/bitcoin_stuff/bmc/new_test/black-market-client$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect login.yahoo.com:443
CONNECTED(00000003)
depth=3 /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
verify return:1
depth=2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
verify return:1
depth=1 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
verify return:1
depth=0 /C=US/ST=CA/L=Sunnyvale/O=Yahoo! Inc./CN=login.yahoo.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=CA/L=Sunnyvale/O=Yahoo! Inc./CN=login.yahoo.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
   i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGOzCCBSOgAwIBAgIQD1hJQVLDNUtt6+cgnnJuZzANBgkqhkiG9w0BAQUFADBm
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSUwIwYDVQQDExxEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBDQS0zMB4XDTEwMTIyMTAwMDAwMFoXDTEzMDEwMzIzNTk1OVowXjELMAkGA1UE
BhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxFDASBgNVBAoU
C1lhaG9vISBJbmMuMRgwFgYDVQQDEw9sb2dpbi55YWhvby5jb20wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBALTxKoODwdPNbM4FrhBYCsIJVm/EtiqQxgHZFBcR
FR8jAKUTXG2rMlkgiAoDp5duez+omwAoULLt9UlRVe6NqBuDxjDcniUeMYyudwzi
ua5EzZGKFryr8kyfhrKz15V4HwDBI1weDHmLDSwuU2jKpUTR1b2jid3o/B95Fd1Z
aUTZAgMBAAGjggNvMIIDazAfBgNVHSMEGDAWgBRQ6nOJ2yn7EI+e5QEg1N55mUiD
9zAdBgNVHQ4EFgQUZwtdzLsVHOGRRhaepLJCXmrYCWMwPgYDVR0RBDcwNYIPbG9n
aW4ueWFob28uY29tgg5tYWlsLnlhaG9vLmNvbYISb3ZpLm1haWwueWFob28uY29t
MHsGCCsGAQUFBwEBBG8wbTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNl
cnQuY29tMEUGCCsGAQUFBzAChjlodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRIaWdoQXNzdXJhbmNlQ0EtMy5jcnQwDgYDVR0PAQH/BAQDAgWgMAwG
A1UdEwEB/wQCMAAwZQYDVR0fBF4wXDAsoCqgKIYmaHR0cDovL2NybDMuZGlnaWNl
cnQuY29tL2NhMy0yMDEwaS5jcmwwLKAqoCiGJmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0
LmNvbS9jYTMtMjAxMGkuY3JsMIIBxgYDVR0gBIIBvTCCAbkwggG1BgtghkgBhv1s
AQMAATCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3Nz
bC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYeggFSAEEAbgB5
ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEAdABl
ACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAg
AG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABh
AG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwBy
AGUAZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBp
AGwAaQB0AHkAIABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABl
AGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wHQYD
VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IBAQBa
Ykl7g9l5hQQzV7XtIdpuNZrTLlJ5y1JUg/GmEbZ7b1kHhBErnibJ3VxgUxA1WUoC
SowYMxCv6E3no+AVe/dJsT3uORihPYyBYM1ST1cto3W/LN2oFCmVQ+PPO7Xje9NE
ZzcHOGHKIBDpA+mggT/Rypntbp9gZX3vuZ51ewxWmfm6w+s17G8kC8gVEyaxtTtV
EEJJquWwLQm5IonuGzMfT93ajAY04aNrJSUg4tzwlsBM6opebNP51jvr2xwecV22
YFFWlT2IK/Hgt5sShRLF87RfM/gfjSCi8g3a0p3CbXeBigaypv/MEGUkcWkfGxwn
fPjh72mmPGC70nR7ikji
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=Sunnyvale/O=Yahoo! Inc./CN=login.yahoo.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
---
No client certificate CA names sent
---
SSL handshake has read 4474 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID:
    Session-ID-ctx:
    Master-Key: D8C808E8BCD16151231DFCEBC6AF1A8AACBA5B464AB5EB8DF5B7DF07C5E0BF7C1F42AF61328907B 8B2E94971760D3B35
    Key-Arg   : None
    Start Time: 1312129871
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Compare with Google ...

ben@ben-laptop2:~/bitcoin_stuff/bmc/new_test/black-market-client$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect encrypted.google.com:443
CONNECTED(00000003)
depth=2 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
verify return:1
depth=1 /C=US/O=Google Inc/CN=Google Internet Authority
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFCDCCBHGgAwIBAgIKPlKuxgADAAAsXDANBgkqhkiG9w0BAQUFADBGMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu
dGVybmV0IEF1dGhvcml0eTAeFw0xMTA3MTMwNTUwNDhaFw0xMjA3MTMwNjAwNDha
MGYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N
b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRUwEwYDVQQDFAwqLmdv
b2dsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANolbE9Pl1R3CLfX
FMXlZJoIvv2548Ksuv4TWfna37sre4Ng7V3vVpwRT0oQteVPGUyiHj/HCqThg3Jz
TNUCFMwhYruXHLtCDO8bcJdvQzTsOKxtYNiopPW3817gbEkuHGhRxCTZtGXFu2Qa
TuQi8BRMzfxUNHPlNvZQAHaR0BadAgMBAAGjggLbMIIC1zAdBgNVHQ4EFgQUTNjK
1Y39on/YBjL7JosCkSI+oJswHwYDVR0jBBgwFoAUv8Aw6/VDET5nup6R+/xq2uNr
EiQwWwYDVR0fBFQwUjBQoE6gTIZKaHR0cDovL3d3dy5nc3RhdGljLmNvbS9Hb29n
bGVJbnRlcm5ldEF1dGhvcml0eS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS5jcmww
ZgYIKwYBBQUHAQEEWjBYMFYGCCsGAQUFBzAChkpodHRwOi8vd3d3LmdzdGF0aWMu
Y29tL0dvb2dsZUludGVybmV0QXV0aG9yaXR5L0dvb2dsZUludGVybmV0QXV0aG9y
aXR5LmNydDAhBgkrBgEEAYI3FAIEFB4SAFcAZQBiAFMAZQByAHYAZQByMIIBqwYD
VR0RBIIBojCCAZ6CDCouZ29vZ2xlLmNvbYIKZ29vZ2xlLmNvbYILKi5hdGdnbC5j
b22CDSoueW91dHViZS5jb22CC3lvdXR1YmUuY29tggsqLnl0aW1nLmNvbYIPKi5n
b29nbGUuY29tLmJygg4qLmdvb2dsZS5jby5pboILKi5nb29nbGUuZXOCDiouZ29v
Z2xlLmNvLnVrggsqLmdvb2dsZS5jYYILKi5nb29nbGUuZnKCCyouZ29vZ2xlLnB0
ggsqLmdvb2dsZS5pdIILKi5nb29nbGUuZGWCCyouZ29vZ2xlLmNsggsqLmdvb2ds
ZS5wbIILKi5nb29nbGUubmyCDyouZ29vZ2xlLmNvbS5hdYIOKi5nb29nbGUuY28u
anCCCyouZ29vZ2xlLmh1gg8qLmdvb2dsZS5jb20ubXiCDyouZ29vZ2xlLmNvbS5h
coIPKi5nb29nbGUuY29tLmNvgg8qLmdvb2dsZS5jb20udm6CDyouZ29vZ2xlLmNv
bS50coINKi5hbmRyb2lkLmNvbYIUKi5nb29nbGVjb21tZXJjZS5jb20wDQYJKoZI
hvcNAQEFBQADgYEAs5zPchwKQuQNN1h+fPdcSUrzSFFXZ5VettWXTbTNKsikctEK
b6cFJKuFqaDa/e7pvxqvVckPRW58sRBpNZTyjbS9XUPHACAVq5f20sPo/Oo47pf/
oMq/xUN7RdgOn+oCoRZO856maRUT2WhrBNAKdZ7RqLihUP7zW+33i6c6Gzc=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority
---
No client certificate CA names sent
---
SSL handshake has read 2144 bytes and written 307 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 5269009FC24EF94B0C80BE4C78369CAC34793554D0E09C90F1F3FD4471DACCA9
    Session-ID-ctx:
    Master-Key: D2F3F86EF29FA4F2A8675476E3546664D85DD819542104AB6F861C590CCC48CD98F4F5131918902 05F80D7CC7284A295
    Key-Arg   : None
    Start Time: 1312129735
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Yep, the latest set of changes allow the client to work, without any verification of the SSL certificates.

However, I am interested in getting SSL certificate verification in the client working again, as that is important, particularly for software for trading.

I've spent some time researching and believe I have a reason for the problem ...

pycurl utilises libgnutls. We can utilise gnutls-cli to check what's going on when GnuTLS is used to connect to glbse.com server ...

ben@ben-laptop2:~/bitcoin_stuff/bmc/new_test/black-market-client$ gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt glbse.com
Processed 142 CA certificate(s).
Resolving 'glbse.com'...
Connecting to '195.200.253.239:443'...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1023 bits
 - Peer's public key: 1023 bits
- Certificate type: X.509
 - Got a certificate list of 3 certificates.
 - Certificate[0] info:
  - subject `serialNumber=ihbeLvU08wDc8R9L8WnCx/p8NSlr31ij,C=IE,O=glbse.com,OU=GT03597358,OU=See www.rapidssl.com/resources/cps (c)11,OU=Domain Control Validated - RapidSSL(R),CN=glbse.com', issuer `C=US,O=GeoTrust\, Inc.,CN=RapidSSL CA', RSA key 2048 bits, signed using RSA-SHA, activated `2011-07-26 20:43:11 UTC', expires `2012-07-28 13:33:05 UTC', SHA-1 fingerprint `06b65248bef97357fb9dfd648671261ee7f4ed9c'
 - Certificate[1] info:
  - subject `C=US,O=GeoTrust Inc.,OU=Domain Validated SSL,CN=GeoTrust DV SSL CA', issuer `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA', RSA key 2048 bits, signed using RSA-SHA, activated `2010-02-26 21:32:31 UTC', expires `2020-02-25 21:32:31 UTC', SHA-1 fingerprint `bae30b15dbb1544cf194d076b75b7bb9e3d6b760'
 - Certificate[2] info:
  - subject `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA', issuer `C=US,O=Equifax,OU=Equifax Secure Certificate Authority', RSA key 2048 bits, signed using RSA-SHA, activated `2002-05-21 04:00:00 UTC', expires `2018-08-21 04:00:00 UTC', SHA-1 fingerprint `7359755c6df9a0abc3060bce369564c8ec4542a3'
- The hostname in the certificate matches 'glbse.com'.
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
*** Verifying server certificate failed...


This suggests the reason for the failure is a missing certificate in the chain presented by the glbse.com server.

So chain presented as a result of negotiation for GnuTLS is as follows ...

server certificate ...
subject `serialNumber=ihbeLvU08wDc8R9L8WnCx/p8NSlr31ij,C=IE,O=glbse.com,OU=GT03597358,OU=See www.rapidssl.com/resources/cps (c)11,OU=Domain Control Validated - RapidSSL(R),CN=glbse.com'
issuer `C=US,O=GeoTrust\, Inc.,CN=RapidSSL CA'

intermediate certificate 1 ...
subject `C=US,O=GeoTrust Inc.,OU=Domain Validated SSL,CN=GeoTrust DV SSL CA'
issuer `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA'

intermediate certificate 2 ...
subject `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA'
issuer `C=US,O=Equifax,OU=Equifax Secure Certificate Authority'

So the chain is broken between the server certificate and intermediate certificate 1.

I believe that if the certificate with ...

subject `C=US,O=GeoTrust\, Inc.,CN=RapidSSL CA'
issuer `C=US,O=GeoTrust Inc.,OU=Domain Validated SSL,CN=GeoTrust DV SSL CA'

... is inserted into the presented chain between the server certificate and current intermediate certificate 1, then no additional certificates will need to be shipped with the client, as the `C=US,O=Equifax,OU=Equifax Secure Certificate Authority' certificate is present in the "standard" ca certificate bundle provided with most OSes.

This should just be a matter of configuration on the glbse.com server.

Same result can be concluded from an equivalent command for openssl ...

ben@ben-laptop2:~/bitcoin_stuff/bmc/new_test/black-market-client$ openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect glbse.com:443
CONNECTED(00000003)
depth=0 /serialNumber=ihbeLvU08wDc8R9L8WnCx/p8NSlr31ij/C=IE/O=glbse.com/OU=GT03597358/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=glbse.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /serialNumber=ihbeLvU08wDc8R9L8WnCx/p8NSlr31ij/C=IE/O=glbse.com/OU=GT03597358/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=glbse.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /serialNumber=ihbeLvU08wDc8R9L8WnCx/p8NSlr31ij/C=IE/O=glbse.com/OU=GT03597358/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=glbse.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/serialNumber=ihbeLvU08wDc8R9L8WnCx/p8NSlr31ij/C=IE/O=glbse.com/OU=GT03597358/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=glbse.com
   i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
 1 s:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEvDCCA6SgAwIBAgIDApP8MA0GCSqGSIb3DQEBBQUAMDwxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEUMBIGA1UEAxMLUmFwaWRTU0wgQ0Ew
HhcNMTEwNzI2MjA0MzExWhcNMTIwNzI4MTMzMzA1WjCB2TEpMCcGA1UEBRMgaWhi
ZUx2VTA4d0RjOFI5TDhXbkN4L3A4TlNscjMxaWoxCzAJBgNVBAYTAklFMRIwEAYD
VQQKEwlnbGJzZS5jb20xEzARBgNVBAsTCkdUMDM1OTczNTgxMTAvBgNVBAsTKFNl
ZSB3d3cucmFwaWRzc2wuY29tL3Jlc291cmNlcy9jcHMgKGMpMTExLzAtBgNVBAsT
JkRvbWFpbiBDb250cm9sIFZhbGlkYXRlZCAtIFJhcGlkU1NMKFIpMRIwEAYDVQQD
EwlnbGJzZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDvA02I
8K86MzXzTMsSTkKquowPDvhBy+1PC+Dh0cEgRuVKY2VrG0RjVNph4oLRc8qoG/zp
6pKvNqXw2WJQnfLe2vIi6R8RF9XOihrb4Mt1Wx10sfQI5pj4pnwfb25PYm6iPQ3N
cp3V5J3Mh/ZLQROI8HEY+f6hbNFqD4dRmxjC6/fwhAEPOKWzbfgFAQvlcHUEsnfp
UuwlDAjlh4u9XWDKt7UCet0B0KGZeoIGOBTg0yd/6oxsC1pwUnK/wYymvm7Wg+C3
uW2JqcVJUhENQV0ug7V4XB2m3ZOsAJcxuCnpfYUvANEuVxuQtpqLzBh/IOMWpR45
s8uoiZmy0MwA3xs3AgMBAAGjggEnMIIBIzAfBgNVHSMEGDAWgBRraT1qGEJK3Y8C
ZTn9NSSGeJEWMDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMBQGA1UdEQQNMAuCCWdsYnNlLmNvbTBDBgNVHR8EPDA6MDigNqA0
hjJodHRwOi8vcmFwaWRzc2wtY3JsLmdlb3RydXN0LmNvbS9jcmxzL3JhcGlkc3Ns
LmNybDAdBgNVHQ4EFgQUP/o+0sHdsz2OVB4Jb75h3IkgIr8wDAYDVR0TAQH/BAIw
ADBJBggrBgEFBQcBAQQ9MDswOQYIKwYBBQUHMAKGLWh0dHA6Ly9yYXBpZHNzbC1h
aWEuZ2VvdHJ1c3QuY29tL3JhcGlkc3NsLmNydDANBgkqhkiG9w0BAQUFAAOCAQEA
oI0xm1JOZCCzJb0IXfu2q9aCm7BYNGqAvLyYddqBVNqGgiM5T4xiA1u+wKCHly+Y
dXn/WD90fTCvMyImTBDlWniJ5NurV7cPEQl7PhDZArwMPIyeRmeZRL4ir8glDGHg
3BK3v7do8H4v+JqmV832M5nn0gQnIKYH5q4Iiq7gE7Q8Nv4v9bTAu4TanGQzWM0+
SLYnBblYE/zS4mDPsw5fY63UOsTBw6/88KHFxzaNxQ7qgejn9lHkbNyHHiJSXz8K
jZ34Ns9xn0QpTPdjWc4O6bE2jTq0oD5GknU5tOds706hmI6BcOvuX+wCE0n19XgB
s+8uPV4vn6oGHedQ4G+AMw==
-----END CERTIFICATE-----
subject=/serialNumber=ihbeLvU08wDc8R9L8WnCx/p8NSlr31ij/C=IE/O=glbse.com/OU=GT03597358/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=glbse.com
issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
---
No client certificate CA names sent
---
SSL handshake has read 3840 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 811D3E85204DFA23243755401CB5D600C3B25F15369B1F82D1355AEF9A5BC38E
    Session-ID-ctx:
    Master-Key: 19C2F072E2A174ADD41A9164FB5AD9C1811001A8796B4A8BDC65A1CEE28C9C3D0F9832FF5677627 CC1F737CBDB5F11D5
    Key-Arg   : None
    Start Time: 1312129418
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)



Thoughts

okay i stand corrected. it was a case of PEBKAC, apparently I still don't fully understand git. the latest commits weren't showing up in the tortoise-git log and doing fetches didn't help either. one of the descriptions of pull I had read made me hesitant to try that again. it's working for me with the latest commits from july 28. thanks.

The ssl cert (that's in the git project) isn't used now and the client has been changed to not verify ssl certificates. Try to get the latest version of bmc.py, Ive tried the client on debian and it works.

from what I can tell it's because openssl doesn't trust the certificate. I tried adding it to the windows trust store and that certainly did not help. i didn't try very hard, but I wasn't able to find the necessary openssl command. looking at the crt file, I didn't see a trust chain in it, so that might explain why it's not trusted.

Anyone else seeing the following error ? ...

ben@ben-laptop2:~/bitcoin_stuff/bmc/black-market-client$ ./bmc.py balance
Enter passphrase:
Server error: server certificate verification failed. CAfile: server.crt CRLfile: none.

This is with a fresh local clone of the git project, as per below.

If you're using the command line client check this.
http://forum.bitcoin.org/index.php?topic=32569.0