Problem:
server:~/myCA # openssl ca -out certs/server.cert.pem -days 1461 -keyfile private/myCA.key.pem -extensions v3_ca_has_san -config ./openssl.cnf -infiles requests/server.req.pem
Using configuration from ./openssl.cnf
Enter pass phrase for private/myCA.key.pem:
Check that the request matches the signature
Signature ok
The countryName field needed to be the same in the
CA certificate (AU) and the request (US)
server:~/myCA #
Uh-oh? Why can't I sign a certificate with my CA setup in Australia, for a server in the USA?
Simple, the CA's openssl.cnf is required to "match" the country name (and other parameters).
(i.e. requested cert's much match parameters in the signing CA)
Alter these in the CA's openssl.cnf to "supplied" instead:
[ policy_match ]
countryName = supplied
stateOrProvinceName = supplied
organizationName = supplied
Wednesday, August 19, 2009
SSL keys for a webserver
Here's how I generate SSL keys for a webserver.
In particular I want name-based vhosts with SSL - this can only be done with multiple DNS names in the certificate...
Most of my openssl setup has been guided by:
http://www.phildev.net/ssl/opensslconf.xhtml
http://www.phildev.net/ssl/creating_ca.xhtml
http://www.phildev.net/ssl/managing_ca.xhtml
with a little info from here:
http://wiki.cacert.org/wiki/VhostTaskForce#A1.Way.3ASubjectAltNameOnly
step 1.... get openssl.cnf as you want it
step 2.... add multiple dns names as required
[alt_names]
DNS.1 = example.net
DNS.2 = www.example.net
DNS.3 = example.com
DNS.4 = www.example.com
DNS.5 = mms.example.com
DNS.6 = fancy.example.org
step 3.... generate key:
openssl genrsa -out example.net.key.pem 4096
step 4.... generate cert
openssl req -config ./openssl.cnf -new -key example.net.key.pem -out example.net.req.pem
use one of the names as the CN..
usually I'd say use the DNS A record as the CN (i.e. if example.net -> a specific IP, and that IP's PTR is example.net)... and then put all the C-names in as DNS (as well as the A-rec) (i.e. the DNS aliases, www.example.net = example.net)
step 5.... transfer the req to the CA and sign it
openssl ca -out certs/example.net.cert.pem -days 1461 -keyfile private/theCA.key.pem -extensions v3_ca_has_san -config ./openssl.cnf -infiles requests/example.net.req.pem
how does it end up?
One CN:
Subject: C=AU, ST=Victoria, O=example, OU=example dot net, CN=example.net/emailAddress=security@example.net
Multiple DNS's
X509v3 Subject Alternative Name:
DNS:example.net, DNS:www.example.net[...]
In particular I want name-based vhosts with SSL - this can only be done with multiple DNS names in the certificate...
Most of my openssl setup has been guided by:
http://www.phildev.net/ssl/opensslconf.xhtml
http://www.phildev.net/ssl/creating_ca.xhtml
http://www.phildev.net/ssl/managing_ca.xhtml
with a little info from here:
http://wiki.cacert.org/wiki/VhostTaskForce#A1.Way.3ASubjectAltNameOnly
step 1.... get openssl.cnf as you want it
step 2.... add multiple dns names as required
[alt_names]
DNS.1 = example.net
DNS.2 = www.example.net
DNS.3 = example.com
DNS.4 = www.example.com
DNS.5 = mms.example.com
DNS.6 = fancy.example.org
step 3.... generate key:
openssl genrsa -out example.net.key.pem 4096
step 4.... generate cert
openssl req -config ./openssl.cnf -new -key example.net.key.pem -out example.net.req.pem
use one of the names as the CN..
usually I'd say use the DNS A record as the CN (i.e. if example.net -> a specific IP, and that IP's PTR is example.net)... and then put all the C-names in as DNS (as well as the A-rec) (i.e. the DNS aliases, www.example.net = example.net)
step 5.... transfer the req to the CA and sign it
openssl ca -out certs/example.net.cert.pem -days 1461 -keyfile private/theCA.key.pem -extensions v3_ca_has_san -config ./openssl.cnf -infiles requests/example.net.req.pem
how does it end up?
One CN:
Subject: C=AU, ST=Victoria, O=example, OU=example dot net, CN=example.net/emailAddress=security@example.net
Multiple DNS's
X509v3 Subject Alternative Name:
DNS:example.net, DNS:www.example.net[...]
Saturday, August 15, 2009
Wii and the Edimax 7206-APg
Tonight I upgraded the Edimax 7206-APg from the somewhat unstable 1.22 firmware, to the newer 1.31. I am surprised they are still developing for this particular model - 1.26 firmware was available for a long long time before 1.31 came out this year.
Anyway, I tried setting "Authentication Type" to shared key, instead of open system... not that it should make a different in a WPA2 environment, but I had a theory that a laptop I have might stop dropping out and then saying "insecure" if I changed it.
On shared key however, the Wii refused to connect (51030). So I tried the auto setting. No good either. Back to open system - now it works.
While thinking about the Wii + wireless, another annoying thing about the Wii is that it requires a B+G wireless environment. Pure G does not work. It has to be both B and G. Frustrating.
My observations are that the Wii starts on 802.11b and then negotiates its' way up the speeds until 11mbit is going, at which point it negotiates its' way onto 802.11g and faster again through all the speeds. Quite bizarre. Why not start at 55mbit and work its' way down if it has to?...
Anyway, I tried setting "Authentication Type" to shared key, instead of open system... not that it should make a different in a WPA2 environment, but I had a theory that a laptop I have might stop dropping out and then saying "insecure" if I changed it.
On shared key however, the Wii refused to connect (51030). So I tried the auto setting. No good either. Back to open system - now it works.
While thinking about the Wii + wireless, another annoying thing about the Wii is that it requires a B+G wireless environment. Pure G does not work. It has to be both B and G. Frustrating.
My observations are that the Wii starts on 802.11b and then negotiates its' way up the speeds until 11mbit is going, at which point it negotiates its' way onto 802.11g and faster again through all the speeds. Quite bizarre. Why not start at 55mbit and work its' way down if it has to?...
Subscribe to:
Posts (Atom)