RE: FAQ on creating certificates for every language

Very good. I did the same with Microsoft's certreq tool a year or more ago,
using a different syntax to openssl for the input template. Same idea,
different tool. Like you, I view the cert in something that prints hex, take
the mod literal, and edit my foaf card. I find the practice very effective,
and easy to script. My scripts leverage sample scripts from Windows WIF SDK,
which install the certs in cert stores, arm https endpoints, setup up
policies like: cert must have extensions, revocation is done automatically,
cert's validation uses a particular cert store when discovery cert chains to
a root, cert chain following sees a URI in the AIA field and goes and gets
the .crt file of its parent directly from the web, etc.

I don't trust public websites to be a cert manufacturer, unless its part of
a payment scheme like VISA (a major social institution that distributes
risk, using "global" governance mechanisms). Good cert minting is an OFFLINE
process, otherwise. 

Such sites are nice demos, though - assuming you have a browser that uses
their HTML tags. Typically, the operator will soon start to act like a
public CA, imposing terms and conditions, and governance rules. They will
start copyrighting the issuer name, etc etc etc, and re-creating the usual
implied threat culture. The operator of the CA issuing the server cert for
the issuing endpoint will try to get in on the governance act, claiming it
has some jurisdiction over the content distributed over the channel (though
shalt not distribute "objectionable" material using this server cert....
where objectionable is ill-defined).


-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Mo McRoberts
Sent: Friday, April 08, 2011 1:49 AM
To: Henry Story
Cc: WebID XG
Subject: Re: FAQ on creating certificates for every language

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=C1C853D53C1181DBCF6E92A1B0C21557095EEA4CCCC28E06EFD44FD3103DB0AEF6DD
DFB63C9FD45ADC982A8E5109DF5919E03ABE435719B913A90F6DE8DED671658956913FA3A28F
BBFAF1DB0852D3E8A658DBC7D3932D9B250A52270C5270FA11F9EA2BEB138FE7521B3AF06ADC
A7CA6D10750DB889BB4971FEA3AE198221877D1578D8EDF127FCDD5EB77082F037A0E67E12E0
9EC37971984F644102602C4B14F956008CF7634EDC6E2826751891F811751156B8316DFC8744
06645A3B9DDF2D563343A55D1D1FA9DC5F72A560DB1216F159B4F986228576474149E8AD52A2
55E62D9EE32B098D1A25A42FF681D1338A6D205C011869A70CAAEC96C2E86257

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="C1C853D53C1181DBCF6E92A1B0C21557095EEA4CCCC28E06EFD44FD3103DB0AEF6
DDDFB63C9FD45ADC982A8E5109DF5919E03ABE435719B913A90F6DE8DED671658956913FA3A2
8FBBFAF1DB0852D3E8A658DBC7D3932D9B250A52270C5270FA11F9EA2BEB138FE7521B3AF06A
DCA7CA6D10750DB889BB4971FEA3AE198221877D1578D8EDF127FCDD5EB77082F037A0E67E12
E09EC37971984F644102602C4B14F956008CF7634EDC6E2826751891F811751156B8316DFC87
4406645A3B9DDF2D563343A55D1D1FA9DC5F72A560DB1216F159B4F986228576474149E8AD52
A255E62D9EE32B098D1A25A42FF681D1338A6D205C011869A70CAAEC96C2E86257" />
</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,keyCer
tSign
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.

Received on Friday, 8 April 2011 14:09:25 UTC