Supply client certificate chain.

svn path=/scripts/http-client.py; revision=836

1 files changed, 29 insertions, 2 deletions

diff --git a/scripts/http-client.py b/scripts/http-client.py
index 815270ad..e1c4ce28 100644
--- a/scripts/http-client.py
+++ b/scripts/http-client.py
@@ -1,8 +1,35 @@
 # $Id$
 
-import httplib
+import httplib, tlslite.api
 
-http = httplib.HTTPSConnection("localhost", 8080)
+certChain = []
+for file in ("biz-certs/Dave-EE.cer", "biz-certs/Dave-CA.cer"):
+  f = open(file, "r")
+  x509 = tlslite.api.X509()
+  x509.parse(f.read())
+  f.close()
+  certChain.append(x509)
+certChain = tlslite.api.X509CertChain(certChain)
+
+f = open("biz-certs/Dave-EE.key", "r")
+privateKey = tlslite.api.parsePEMKey(f.read(), private=True)
+f.close()
+
+# There doesn't seem to be any existing OpenSSL-based python HTTPS
+# client which bothers to check the server's certificate.  tlslite
+# does check, but only when it's using cryptlib...which doesn't
+# compile on FreeBSD this week due to a completely unrelated symbol
+# collision with another FreeBSD package (don't ask).
+#
+# The mechanism that requires cryptlib is the x509TrustList parameter to
+# tlslite.api.HTTPTLSConnection(), which looks just about perfect other
+# than requiring cryptlib.   Not sure how much work it would be to get
+# this to work with M2Crypto (would help if M2Crypto were documented).
+#
+# For the moment, just punt on the issue, as this is test code.  In
+# production this would be a problem.
+
+http = tlslite.api.HTTPTLSConnection(host="localhost", port=8080, certChain=certChain, privateKey=privateKey)
 
 http.connect()
 http.request("POST", "/", "This is a test.  This is only a test.  Had this been real you would now be really confused.\n", {"Content-Type":"application/wombat"})