You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: services/create_ssl_certs.md
+33-21Lines changed: 33 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,22 +1,32 @@
1
1
# Certificate Management
2
2
3
-
## Creating TLS Certificates
3
+
## Managing TLS Certificates for sites on our load balancers
4
+
Most of our sites are served from our load balancers - any site that is configured by a file in the `nginxplus` role in princeton_ansible is served from the load balancers.
4
5
5
-
### For sites on the .princeton.edu domain
6
+
### Creating certificates for sites on our load balancers with ACME
6
7
7
-
1. You can create auto-renewing certificates and keys directly on the load balancers for sites in the .princeton.edu domain. You can create a single certificate and key with [playbooks/incommon_certbot.yml](https://github.com/pulibrary/princeton_ansible/blob/main/playbooks/incommon_certbot.yml) or create a single certificate with multiple names and keys with [playbooks/incommon_certbot_multi.yml](https://github.com/pulibrary/princeton_ansible/blob/main/playbooks/incommon_certbot_multi.yml)
8
+
1. You can create certificates and keys directly on the load balancers for sites that are served from them. You can create a single certificate and key with [playbooks/incommon_certbot.yml](https://github.com/pulibrary/princeton_ansible/blob/main/playbooks/incommon_certbot.yml) or create a single certificate with multiple names and keys with [playbooks/incommon_certbot_multi.yml](https://github.com/pulibrary/princeton_ansible/blob/main/playbooks/incommon_certbot_multi.yml). All certificates created with these playbooks will automatically renew using ACME and certbot.
8
9
9
10
1. You will need to run the above playbook on each load balancer sequentially
10
11
1. If the certificate already exists you will need to revoke it before running your chosen playbook
11
12
12
-
### For sites outside the Princeton domain
13
+
### Revoking certificates for sites on our load balancers
13
14
14
-
1. Create a new entry under [sites](https://github.com/pulibrary/princeton_ansible/blob/dac77a6c2e0f1301201c9b2a63b9ebead5f7b7ac/group_vars/nginxplus/production.yml#L16)
15
-
2. Run the [nginxplus playbook](https://github.com/pulibrary/princeton_ansible/blob/main/playbooks/nginxplus.yml)
16
-
3. Your TLS/SSL cert will be on the production loadbalancer
17
-
4. Verify the files you get back and add them to your server configuration.
15
+
When we decommission a site, we need to revoke the certificates for that site.
18
16
19
-
## Verifying certbot certificate renewals
17
+
#### Revoking ACME Certificates
18
+
19
+
For auto-renewing ACME certificates, use playbooks/incommon_certbot.yml](https://github.com/pulibrary/princeton_ansible/blob/main/playbooks/incommon_certbot_revoke.yml). As with the playbook that creates certificates, you must run the revoke playbook on each load balancer sequentially.
20
+
21
+
#### Revoking manual Certificates
22
+
23
+
For certificates that were created manually, there is a [ServiceNow form](https://princeton.service-now.com/service?id=sc_cat_item&sys_id=2e7ffb64dbad9114e8c283aa13961993) for revoking certificates. You can search in the dropdown by certificate ID or by site name. Note that the site name search only matches the full name - for example, to match `lib-aeon.princeton.edu` you must type `lib-aeon`; if you type `aeon` it will say there are no matching entries.
24
+
25
+
Select the certificate you want to revoke, enter a reason, and hit Submit. The process is very quick - refresh the form to confirm that the revoked certificate is no longer listed.
26
+
27
+
If you use the ServiceNow form to revoke an ACME certificate, certbot will renew it the next day. You must use the playbook to revoke ACME certificates.
28
+
29
+
## Verifying certbot renewals of ACME certificates
20
30
21
31
To verify that a certificate on a server will auto-renew:
22
32
@@ -28,14 +38,19 @@ This command checks all certs that certbot knows about on that server.
28
38
29
39
Our certificate management system is Sectigo. Operations folks can [log into Sectigo](https://cert-manager.com/customer/InCommon) using their alias email accounts and individual passwords. We can view certificate status there, but we cannot revoke or renew certificates there.
30
40
31
-
## Manually managed certs list
41
+
## Managing TLS certificates for sites that do not run on our load balancers
32
42
33
-
These certs are not managed by our usual process. These certs cover:
43
+
We have a few sites that need a different approach to certificate management. These sites include:
34
44
35
-
- sites we do not serve from the load balancers
45
+
- sites we run on individual servers or in the cloud
36
46
- vendor-hosted sites with the '.princeton.edu' extension
47
+
- sites we serve from the load balancers with extensions other than '.princeton.edu'
48
+
49
+
Many of these certs must be deployed manually. Some must also be renewed manually.
50
+
51
+
If a private key is kept in princeton_ansible, it is encrypted as a file in the `/keys/` directory of the repo.
37
52
38
-
Many of these certs must be deployed manually. Some must also be renewed manually. If a private key is kept in princeton_ansible, it is encrypted as a file in the `/keys/` directory of the repo.
53
+
Here is the current list:
39
54
40
55
cicognara.org
41
56
* Purpose: public site for the Cicognara collection (a collaborative project)
@@ -128,6 +143,7 @@ scsb.recaplib.org
128
143
* Purpose: external hosted service for research collections
129
144
* Managed: on DNSimple and Vendor's AWS Certificate Manager
130
145
* Deployed: by vendor and CNAME validation on DNSimple
146
+
* If ever there is a change in the application vendor will provide CNAME which can be added to DNSimple configuration
131
147
132
148
simrisk.pulcloud.io
133
149
* Purpose: experimental application for CDH
@@ -138,18 +154,14 @@ simrisk.pulcloud.io
138
154
tigris.princeton.edu
139
155
* Purpose: hosted service for University Records management
140
156
* Managed: in ServiceNow, private key is in princeton_ansible
141
-
* Deployed: by vendor; to update, email a .pfx file of the cert to <[email protected]>
142
-
143
-
### scsb
144
-
145
-
If ever there is a change in the application vendor will provide CNAME which can be added to DNSimple configuration
157
+
* Deployed: by vendor; to update, email a .pfx file of the cert to <[email protected]>; see details below
146
158
147
-
#### Tigris
159
+
#### Tigris renewals
148
160
149
161
In July of every year [tigris.princeton.edu](tigris.princeton.edu) will get an automatic renewal. The following steps will be needed to ensure the certificate remains renewed.
150
162
151
-
- Open a ticket with tigris (aka Gimmal) support at <[email protected]> and ask who should receive the new chained file.
152
-
- You will need the [vaulted private key](https://github.com/pulibrary/princeton_ansible/blob/main/keys/tigris_princeton_edu_priv.key) and the certificate and intermediate certificate to generate a pfx file that you will ship to the vendor
163
+
* Open a ticket with tigris (aka Gimmal) support at <[email protected]> and ask who should receive the new chained file.
164
+
* You will need the [vaulted private key](https://github.com/pulibrary/princeton_ansible/blob/main/keys/tigris_princeton_edu_priv.key) and the certificate and intermediate certificate to generate a pfx file that you will ship to the vendor
0 commit comments