W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: FAQ on creating certificates for every language

From: Henry Story <henry.story@bblfish.net>
Date: Fri, 8 Apr 2011 11:42:53 +0200
Cc: WebID XG <public-xg-webid@w3.org>
Message-Id: <0A0A6732-7581-441E-9AB4-FDCF7C1ADCEA@bblfish.net>
To: Mo McRoberts <Mo.McRoberts@bbc.co.uk>
Thanks Mo,

  this is very useful. It should find its way on the HOWTO page of the wiki, directly or via a link to a blog  or to this post.

  As a matter of interest the dane list is discussing if self signed certs are CA certs.
http://www.ietf.org/mail-archive/web/dane/current/msg02293.html
  I don't completely follow this. There is talk of EE (end entity certs) and CA certs.

 At some point we will need to work out what the IETF right way is to create a cert, as well as know what works, so that we can specify exactly the minimum needed for WebID certs. Then we could set up a test suite for those, to analyse them, and explain what in the certificate is correct, what is acceptable, what we don't know,... 

   Henry

On 8 Apr 2011, at 10:49, Mo McRoberts wrote:

> Okay, I've arrived the absolute bare minimum required to create a self-signed WebID certificate via command-line OpenSSL. In practice, you'd probably want to do more than this (especially for compatibility)…
> 
> The below example assumes a WebID subject URI of http://hideyhole.nexgenta.com/2011/webid#me
> 
> First, you need to create a config file, which I've called req.conf:
> 
> [ req ]
> default_bits = 2048
> default_md = sha1
> distinguished_name = distinguished_name
> UID = A user ID
> UID_default = http://hideyhole.nexgenta.com/2011/webid\#me
> 
> [ distinguished_name ]
> commonName = Common Name
> commonName_default = WebID
> 
> [ req_ext ]
> subjectAltName=critical,@subject_alt
> 
> [ subject_alt ]
> URI.1=http://hideyhole.nexgenta.com/2011/webid\#me
> 
> Next, the OpenSSL invocation itself:
> 
> openssl req -new -batch -config req.conf -out webid.pem -extensions req_ext -x509
> 
> This will produce the following output (prompting for a passphrase to protect the private key):
> 
> Generating a 2048 bit RSA private key
> ..................................................q..........+++
> ..............................................................................................................................................+++
> writing new private key to 'privkey.pem'
> Enter PEM pass phrase:
> Verifying - Enter PEM pass phrase:
> -----
> 
> You'll be left with three files: req.conf created above, privkey.pem — your RSA private key, protected by the PEM passphrase you typed in, and webid.pem, which is the actual self-signed certificate.
> 
> You can use the following to print the modulus and exponent of the new key:
> 
> openssl rsa -in privkey.pem -modulus -noout
> 
> ...this will print something like:
> 
> Enter pass phrase for privkey.pem:
> Modulus=C1C853D53C1181DBCF6E92A1B0C21557095EEA4CCCC28E06EFD44FD3103DB0AEF6DDDFB63C9FD45ADC982A8E5109DF5919E03ABE435719B913A90F6DE8DED671658956913FA3A28FBBFAF1DB0852D3E8A658DBC7D3932D9B250A52270C5270FA11F9EA2BEB138FE7521B3AF06ADCA7CA6D10750DB889BB4971FEA3AE198221877D1578D8EDF127FCDD5EB77082F037A0E67E12E09EC37971984F644102602C4B14F956008CF7634EDC6E2826751891F811751156B8316DFC874406645A3B9DDF2D563343A55D1D1FA9DC5F72A560DB1216F159B4F986228576474149E8AD52A255E62D9EE32B098D1A25A42FF681D1338A6D205C011869A70CAAEC96C2E86257
> 
> You can then update your FOAF with:
> 
> <rsa:RSAPublicKey>                                                            
>    <cert:identity rdf:resource="http://hideyhole.nexgenta.com/2011/webid#me" />
>    <rsa:public_exponent cert:decimal="65537" />
>    <rsa:modulus cert:hex="C1C853D53C1181DBCF6E92A1B0C21557095EEA4CCCC28E06EFD44FD3103DB0AEF6DDDFB63C9FD45ADC982A8E5109DF5919E03ABE435719B913A90F6DE8DED671658956913FA3A28FBBFAF1DB0852D3E8A658DBC7D3932D9B250A52270C5270FA11F9EA2BEB138FE7521B3AF06ADCA7CA6D10750DB889BB4971FEA3AE198221877D1578D8EDF127FCDD5EB77082F037A0E67E12E09EC37971984F644102602C4B14F956008CF7634EDC6E2826751891F811751156B8316DFC874406645A3B9DDF2D563343A55D1D1FA9DC5F72A560DB1216F159B4F986228576474149E8AD52A255E62D9EE32B098D1A25A42FF681D1338A6D205C011869A70CAAEC96C2E86257" />
> </rsa:RSAPublicKey>
> 
> In practice, you'll probably want a slightly beefier set of certificate extensions, so it's probably a good idea to amend the req_ext section of req.conf to instead read:
> 
> [ req_ext ]
> subjectKeyIdentifier=hash
> subjectAltName=critical,@subject_alt
> basicConstraints = critical,CA:false
> keyUsage = critical,digitalSignature,nonRepudiation,keyEncipherment,keyAgreement,keyCertSign
> extendedKeyUsage = critical,clientAuth
> nsCertType = client,email
> 
> OpenSSL will, by default, re-use the existing 'privkey.pem' if it's present, rather than generating a fresh one each time.
> 
> You can run the following the dump the contents of the certificate as text:
> 
> openssl x509 -in webid.pem -noout -text
> 
> ...which will produce something like:
> 
> Certificate:
>    Data:
>        Version: 3 (0x2)
>        Serial Number:
>            aa:d0:72:00:2d:96:86:3a
>        Signature Algorithm: sha1WithRSAEncryption
>        Issuer: CN=WebID/UID=http://hideyhole.nexgenta.com/2011/webid#me
>        Validity
>            Not Before: Apr  8 08:36:04 2011 GMT
>            Not After : May  8 08:36:04 2011 GMT
>        Subject: CN=WebID/UID=http://hideyhole.nexgenta.com/2011/webid#me
>        Subject Public Key Info:
>            Public Key Algorithm: rsaEncryption
>            RSA Public Key: (2048 bit)
>                Modulus (2048 bit):
>                    00:c1:c8:53:d5:3c:11:81:db:cf:6e:92:a1:b0:c2:
>                    15:57:09:5e:ea:4c:cc:c2:8e:06:ef:d4:4f:d3:10:
>                    3d:b0:ae:f6:dd:df:b6:3c:9f:d4:5a:dc:98:2a:8e:
>                    51:09:df:59:19:e0:3a:be:43:57:19:b9:13:a9:0f:
>                    6d:e8:de:d6:71:65:89:56:91:3f:a3:a2:8f:bb:fa:
>                    f1:db:08:52:d3:e8:a6:58:db:c7:d3:93:2d:9b:25:
>                    0a:52:27:0c:52:70:fa:11:f9:ea:2b:eb:13:8f:e7:
>                    52:1b:3a:f0:6a:dc:a7:ca:6d:10:75:0d:b8:89:bb:
>                    49:71:fe:a3:ae:19:82:21:87:7d:15:78:d8:ed:f1:
>                    27:fc:dd:5e:b7:70:82:f0:37:a0:e6:7e:12:e0:9e:
>                    c3:79:71:98:4f:64:41:02:60:2c:4b:14:f9:56:00:
>                    8c:f7:63:4e:dc:6e:28:26:75:18:91:f8:11:75:11:
>                    56:b8:31:6d:fc:87:44:06:64:5a:3b:9d:df:2d:56:
>                    33:43:a5:5d:1d:1f:a9:dc:5f:72:a5:60:db:12:16:
>                    f1:59:b4:f9:86:22:85:76:47:41:49:e8:ad:52:a2:
>                    55:e6:2d:9e:e3:2b:09:8d:1a:25:a4:2f:f6:81:d1:
>                    33:8a:6d:20:5c:01:18:69:a7:0c:aa:ec:96:c2:e8:
>                    62:57
>                Exponent: 65537 (0x10001)
>        X509v3 extensions:
>            X509v3 Subject Alternative Name: critical
>                URI:http://hideyhole.nexgenta.com/2011/webid#me
>    Signature Algorithm: sha1WithRSAEncryption
>        73:e9:b0:f2:b2:0c:93:f7:e9:9f:88:00:31:98:db:7d:86:4d:
>        d8:59:54:eb:f6:f7:3c:aa:6a:c4:0f:9d:6e:18:c2:9f:97:4c:
>        21:d4:84:7c:75:9e:a5:9d:b4:24:40:bc:71:f1:de:fc:ee:ac:
>        51:a6:11:f3:3b:56:1c:09:a7:e8:21:ca:ee:dd:49:e1:32:db:
>        f8:3d:1e:3b:02:8a:f6:16:e5:e4:a1:d7:21:79:7c:39:81:05:
>        56:0d:2b:bf:56:f2:42:92:4b:d1:fb:4f:fb:92:7b:67:dc:58:
>        a6:55:9b:57:71:a8:8a:2e:f5:7b:ad:f6:06:86:61:1d:52:ca:
>        9f:f6:5a:1e:99:0e:b1:89:56:cc:e4:ad:ab:e1:84:9d:db:6a:
>        4d:9b:6b:16:58:e9:cb:ff:e2:b8:dd:d1:49:a7:80:23:4b:c0:
>        28:4b:b8:90:c7:4f:93:85:48:07:63:c4:f1:a2:72:93:af:99:
>        84:d8:d4:b7:f9:5b:75:29:87:7d:93:2d:d2:68:05:2b:51:6a:
>        1e:05:da:7a:f4:3f:71:dd:e6:d0:3a:b4:67:47:39:dc:54:e6:
>        c9:35:a3:9c:36:71:49:ec:0a:53:d6:ed:44:32:5e:db:b8:62:
>        e1:c3:c9:b3:cd:63:c3:5b:fc:72:06:cc:0f:46:30:96:75:38:
>        18:9d:b9:1d
> 
> Having gone around in circles a few times before discovering that I'd done something very stupid indeed, basic debugging steps are:
> 
> 1. If the certificate isn't accepted by the web server *at all* (i.e., the browser tells you that it's been rejected), then you've ended up with a certificate that's invalid as far as the server's concerned. The rule them out as problems, make sure the certificate hasn't expired yet, and also try one with the extra extensions present. Some servers are picky.
> 
> 2. Check that the “X509v3 Subject Alternative Name” is present (you'll see it in the openssl x509 -in webid.pem -noout -text dump, and most GUI certificate viewers will show you the “Subject Alternative Name”) and has the correct URI. If you're missing the fragment from the URI, it's because you missed the backslash to escape the # in req.conf
> 
> 3. Check your web server's logs. If you're seeing the request being made to your FOAF RDF, then your certificate is fine.
> 
> 4. Make sure your FOAF RDF actually contains the key info...
> 
> (No prizes for guessing which one kept me scratching my head yesterday)
> 
> Hopefully this is helpful!
> 
> M.
> 
> -- 
> Mo McRoberts - Data Analyst - Digital Public Space,
> Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
> Room 7066, BBC Television Centre, London W12 7RJ,
> 0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A
> 
> 
> 
> 
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> 					

Social Web Architect
http://bblfish.net/
Received on Friday, 8 April 2011 09:43:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:23 UTC