Difference between revisions of "Fedora Arm Secondary Architecture/Koji Certificates"
Chris Tyler (talk | contribs) |
|||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Category:Fedora ARM Secondary Architecture]] | + | [[Category:Fedora ARM Secondary Architecture]][[Category:Winter 2010 SBR600]] |
| + | [[Category:Demo]] | ||
| + | = Goal = | ||
| − | + | To create the certificates for the Koji farm. | |
| − | + | = Resources = | |
| − | I managed to break the code down into 2 separate peices. One for making the CA and one for making the certs for the different users. Now the way my script differs from the original is that it uses the variables passed to it as the default commonName in the ssl.cnf file. | + | * [[:fedora:Koji/ServerHowTo]] |
| + | |||
| + | = Scripts = | ||
| + | |||
| + | I managed to break the code down into 2 separate peices. One for making the CA and one for making the certs for the different users. Now the way my cert script differs from the original is that it uses the variables passed to it as the default commonName in the ssl.cnf file. | ||
| + | |||
| + | == Script 1: cascript == | ||
| + | caname=koji | ||
| + | user=$1 | ||
| + | openssl genrsa -out certs/${user}.key 2048 | ||
| + | cat ssl.cnf | sed 's/hongkong/'${user}'/'> ssl2.cnf | ||
| + | openssl req -config ssl2.cnf -new -nodes -out certs/${user}.csr -key certs/${user}.key | ||
| + | openssl ca -config ssl2.cnf -keyfile private/${caname}_ca_cert.key -cert ${caname}_ca_cert.crt \ | ||
| + | -out certs/${user}.crt -outdir certs -infiles certs/${user}.csr | ||
| + | cat certs/${user}.crt certs/${user}.key > ${user}.pem | ||
| + | mv ssl2.cnf confs/${user}-ssl.cnf | ||
| + | [chris@hongkong koji]$ cat cascript | ||
| + | cd /etc/pki/koji/ | ||
| + | mkdir {certs,private,confs} | ||
| + | touch index.txt | ||
| + | echo 01 > serial | ||
| + | caname=koji | ||
| + | openssl genrsa -out private/${caname}_ca_cert.key 2048 | ||
| + | openssl req -config ssl.cnf -new -x509 -days 3650 -key private/${caname}_ca_cert.key \ | ||
| + | -out ${caname}_ca_cert.crt -extensions v3_ca | ||
| + | |||
| + | == Script 2: certscript == | ||
| + | caname=koji | ||
| + | user=$1 | ||
| + | openssl genrsa -out certs/${user}.key 2048 | ||
| + | cat ssl.cnf | sed 's/hongkong/'${user}'/'> ssl2.cnf | ||
| + | openssl req -config ssl2.cnf -new -nodes -out certs/${user}.csr -key certs/${user}.key | ||
| + | openssl ca -config ssl2.cnf -keyfile private/${caname}_ca_cert.key -cert ${caname}_ca_cert.crt \ | ||
| + | -out certs/${user}.crt -outdir certs -infiles certs/${user}.csr | ||
| + | cat certs/${user}.crt certs/${user}.key > ${user}.pem | ||
| + | mv ssl2.cnf confs/${user}-ssl.cnf | ||
| + | |||
| + | = Using the Scripts = | ||
| + | |||
| + | == Using the cascript == | ||
| + | |||
| + | == Using the certscript == | ||
For example, when executing my script to create a cert for a new user...lets say "kojiuser1": | For example, when executing my script to create a cert for a new user...lets say "kojiuser1": | ||
| − | + | ./certscript kojiuser1 | |
The script as usual asks the various questions about where you are from and the OU name and the province etc, etc, but is then followed by the question of what the commonName should be. This name and/or the OU name should always be different from any other certs already created or you will get a TXT_ error. My script makes pressing enter easier by allowing you to press enter knowing that the commonName will be (by default).. "kojiuser1". Now this may not seem like anything huge for the creation of one user but what if we were creating multiple users (which was the case with me). | The script as usual asks the various questions about where you are from and the OU name and the province etc, etc, but is then followed by the question of what the commonName should be. This name and/or the OU name should always be different from any other certs already created or you will get a TXT_ error. My script makes pressing enter easier by allowing you to press enter knowing that the commonName will be (by default).. "kojiuser1". Now this may not seem like anything huge for the creation of one user but what if we were creating multiple users (which was the case with me). | ||
| − | + | for user in arm{1..25}; do ./certscript $user; done | |
| − | |||
| − | |||
| − | |||
In addition, a folder called "confs" holds all the conf files used to make the certs, this makes backtracking easier. For now only one line gets modified but it leaves progression for future endeavours. The only time you need to press a key other than enter is when it asks if you want to sign the cert. Of course 95% of the script remains the same as before but this modification makes life one step easier and hence minimizes the length of the cert creation process. | In addition, a folder called "confs" holds all the conf files used to make the certs, this makes backtracking easier. For now only one line gets modified but it leaves progression for future endeavours. The only time you need to press a key other than enter is when it asks if you want to sign the cert. Of course 95% of the script remains the same as before but this modification makes life one step easier and hence minimizes the length of the cert creation process. | ||
Latest revision as of 15:22, 3 May 2010
Contents
Goal
To create the certificates for the Koji farm.
Resources
Scripts
I managed to break the code down into 2 separate peices. One for making the CA and one for making the certs for the different users. Now the way my cert script differs from the original is that it uses the variables passed to it as the default commonName in the ssl.cnf file.
Script 1: cascript
caname=koji
user=$1
openssl genrsa -out certs/${user}.key 2048
cat ssl.cnf | sed 's/hongkong/'${user}'/'> ssl2.cnf
openssl req -config ssl2.cnf -new -nodes -out certs/${user}.csr -key certs/${user}.key
openssl ca -config ssl2.cnf -keyfile private/${caname}_ca_cert.key -cert ${caname}_ca_cert.crt \
-out certs/${user}.crt -outdir certs -infiles certs/${user}.csr
cat certs/${user}.crt certs/${user}.key > ${user}.pem
mv ssl2.cnf confs/${user}-ssl.cnf
[chris@hongkong koji]$ cat cascript
cd /etc/pki/koji/
mkdir {certs,private,confs}
touch index.txt
echo 01 > serial
caname=koji
openssl genrsa -out private/${caname}_ca_cert.key 2048
openssl req -config ssl.cnf -new -x509 -days 3650 -key private/${caname}_ca_cert.key \
-out ${caname}_ca_cert.crt -extensions v3_ca
Script 2: certscript
caname=koji
user=$1
openssl genrsa -out certs/${user}.key 2048
cat ssl.cnf | sed 's/hongkong/'${user}'/'> ssl2.cnf
openssl req -config ssl2.cnf -new -nodes -out certs/${user}.csr -key certs/${user}.key
openssl ca -config ssl2.cnf -keyfile private/${caname}_ca_cert.key -cert ${caname}_ca_cert.crt \
-out certs/${user}.crt -outdir certs -infiles certs/${user}.csr
cat certs/${user}.crt certs/${user}.key > ${user}.pem
mv ssl2.cnf confs/${user}-ssl.cnf
Using the Scripts
Using the cascript
Using the certscript
For example, when executing my script to create a cert for a new user...lets say "kojiuser1":
./certscript kojiuser1
The script as usual asks the various questions about where you are from and the OU name and the province etc, etc, but is then followed by the question of what the commonName should be. This name and/or the OU name should always be different from any other certs already created or you will get a TXT_ error. My script makes pressing enter easier by allowing you to press enter knowing that the commonName will be (by default).. "kojiuser1". Now this may not seem like anything huge for the creation of one user but what if we were creating multiple users (which was the case with me).
for user in arm{1..25}; do ./certscript $user; done
In addition, a folder called "confs" holds all the conf files used to make the certs, this makes backtracking easier. For now only one line gets modified but it leaves progression for future endeavours. The only time you need to press a key other than enter is when it asks if you want to sign the cert. Of course 95% of the script remains the same as before but this modification makes life one step easier and hence minimizes the length of the cert creation process.
