https://sown-auth.ecs.soton.ac.uk is the login page all clients will be redirected to on connection. The University URL is used so that we meet rules regarding validating University-users passwords.
Auth is not accessible from outside the [ECS] (unless you are connected to a sown node!)
Auth was originally vulnerable to the debian not-so-random-number bug (details). After some security-updates, a new certificate was signed and loaded on the server.
The certificate and keys live under
More information on GeneratingSSLKeys
- Once you have your new crt, based upon a new key, create a new folder in which to place the files, in keeping with existing naming scheme.
- Then create a new chain file for this certificate (see below).
- Update the symlink named
currentto point to the new directory.
- Then stop and start the web server, making sure to type the ssl pass phrase in.
Creating the Cert. Chain file
The chain file contains the certificates of those who have signed our certificate, and those who have signed them, and so forth, until a self-signed certificate is reached. Apache has some documentation on it.
Certs are stored in
/etc/ssl/certs/, indexed by hashes of their subject identifiers.
To find the hash of the issuer use
openssl x509 -noout -issuer_hash -in our_cert.crt.
Use the hash to find the certificate in the
/etc/ssl/certs/ directory, e.g. (
ls -l | grep hash)
If any of the certificates on the chain are not present on the local machine, find them somewhere on the web (sometimes the cert metadata will include a URL for the issuer. Use
openssl x509 -noout -text -in our_cert.crt).
(when written this could be found in our certificate as the
CA Issuers value)
If you download a certificate and find a certificate and find it is in a binary format, change the input format to openssl until you find one where it parses.
wget http://crt.tcs.terena.org/TERENASSLCA.crt cat TERENASSLCA.crt
if the cat looks rubbish...
openssl x509 -inform [DER,NET,PEM] -in TERENASSLCA.crt > TERENASSLCA.pem
repeat this process until you run out of certificates in the chain.
Finally, cat all the certificates into a single file, starting with the parent, then the parent of the parent...etc...; this is your chain file.
If the certificate chain changes then you HAVE to update the configure-wget job on auth and run it against all nodes to ensure all nodes have the new certificate chaining information installed in /etc/ssl/certs/!
All in /srv/www/auth
All new clients are automatically directed to this page: it contains a login form to access the network or the administration pages.
From here users can
- Reset password -> Send email with new password in
- Add users
- Edit Account
- Add guest
- Node Administration
This is where the nodes 'wget' their configuration details from