Merge lp:~allenap/gwacl/readme-pfx-unused into lp:gwacl

[Gavin Panella]

README clean-ups, including removal of unused .pfx generation instructions.

[Julian Edwards (julian-edwards)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 review: approve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlG/tDgACgkQWhGlTF8G/Heh2gCfZZjozF7L+RazAcAjA3dpb4Jf
yUoAoJl4Bt/cny1iUUJzj181Z7DLiPeD
=77sF
-----END PGP SIGNATURE-----

review: Approve

=== modified file 'README'
--- README	2013-03-20 02:48:39 +0000
+++ README	2013-06-17 14:17:30 +0000
@@ -1,49 +1,49 @@
-GWACL - The Go Windows Azure Client Library.
+===========================================
+GWACL - The Go Windows Azure Client Library
+===========================================
+
 
 Random notes, clean this up later
 =================================
 
-You need libcurl
-----------------
-
-The code that communicates with Azure's management API uses libcurl, through a
-Go language binding called go-curl.  Install the libcurl headers and go-curl:
+
+Install libcurl
+---------------
+
+The code that communicates with Azure's management API uses *libcurl*, through
+a Go language binding called *go-curl*.  Install the libcurl headers and
+go-curl::
 
    sudo apt-get install libcurl4-openssl-dev
    go get github.com/andelf/go-curl
 
 On Ubuntu 12.10 at least, you specifically need the given version of libcurl.
-With other versions you will receive unexpected "403" http status codes
+With other versions you will receive unexpected "403" HTTP status codes
 ("Forbidden") from the Azure server.
 
 Why use libcurl?  At the time of writing, Go's built-in http package does not
-support TLS renegotiation.  We find that Azure forces such a renegotiation when
-we access the management API.  The use of libcurl is embedded so that future
-implementations can swap it out for a different http library without breaking
-compatibility.
-
-
-To generate an x509 key to talk to Azure
-----------------------------------------
-
-Run this:
-
-   openssl req -config /usr/share/ssl-cert/ssleay.cnf -x509 -nodes -days 3650 -newkey rsa:2048 -keyout azure.pem -out azure.pem
-
-And then export a certificate that you can upload to Azure's management portal
-(see http://msdn.microsoft.com/en-us/library/windowsazure/gg551726.aspx):
-
-   openssl pkcs12 -export -out azure.pfx -in azure.pem
-
-It'll prompt you for a password.  For our purposes, just leave it blank.
-
-Note the use of the ssleay.cnf - it just contains some crappy defaults so you
-don't get prompted for certificate data.  You can leave it out if you want, but
-then you'll need to enter country, organisation etc.
-
-Azure wants you to upload a .cer file (which is in DER format).  Here's how you
-can extract a .crt file from the .pfx:
+support TLS renegotiation.  We find that Azure forces such a renegotiation
+when we access the management API.  The use of libcurl is embedded so that
+future implementations can swap it out for a different http library without
+breaking compatibility.
+
+
+Generate an x509 key to talk to Azure
+-------------------------------------
+
+Azure requires that API clients use an x509 certificate to authenticate to the
+management API. Create the certificate with::
+
+  openssl req -config /usr/share/ssl-cert/ssleay.cnf -x509 -nodes \
+    -days 3650 -newkey rsa:2048 -keyout azure.pem -out azure.pem
+
+Note the use of ``ssleay.cnf``.  It just contains some crappy defaults so you
+don't get prompted for certificate data.  You can leave it out if you want,
+but then you'll need to enter country, organisation, etc.
+
+Azure wants you to upload a ``.cer`` file (which is in DER format).  Here's
+how you can extract a ``.cer`` file from the ``.pem``::
 
    openssl x509 -inform pem -in azure.pem -outform der -out azure.cer
 
-You can now upload azure.cer to Azure as a management certificate.
+You can now upload ``azure.cer`` to Azure as a management certificate.