... | ... | @@ -106,6 +106,9 @@ The configuration file should be mounted into the container as `/app/config.json |
|
|
"port": 3306,
|
|
|
"database": "certcache"
|
|
|
},
|
|
|
"healthcheck": {
|
|
|
"path": "/api-docs"
|
|
|
},
|
|
|
"introspection": {
|
|
|
"url": "https://authz.itlab.stanford.edu/introspect",
|
|
|
"client_id": "certcache.itlab.stanford.edu",
|
... | ... | @@ -115,9 +118,10 @@ The configuration file should be mounted into the container as `/app/config.json |
|
|
"read": "certcache:read",
|
|
|
"write": "certcache:write"
|
|
|
},
|
|
|
"redis": false,
|
|
|
"revoker": {
|
|
|
"interval": 900
|
|
|
"periodic": {
|
|
|
"interval": 900,
|
|
|
"unknown_days": 7,
|
|
|
"compliance_days": 10
|
|
|
},
|
|
|
"sqs": {
|
|
|
"main": "certcache.fifo",
|
... | ... | @@ -168,6 +172,14 @@ CertCache requires a MySQL database; we're using AWS [RDS](https://aws.amazon.co |
|
|
|
|
|
*NOTE* We did try using the new RDS IAM functionality, but it does not work with current NodeJS MySQL client pooling.
|
|
|
|
|
|
### `healthcheck` Configuration
|
|
|
|
|
|
|Key |Value |Description|
|
|
|
|----|---------|-----------|
|
|
|
|path|/api-docs|path used for requests to /healthcheck endpoint|
|
|
|
|
|
|
The healthcheck endpoint is always available over HTTP.
|
|
|
|
|
|
### `introspection` Configuration
|
|
|
|
|
|
Access to the CertCache API is controlled using [OAuth 2.0](https://tools.ietf.org/html/rfc6749); the API must be configured to use [Token Introspection](https://tools.ietf.org/html/rfc7662) to obtain information about client tokens.
|
... | ... | @@ -198,13 +210,24 @@ If `redis` is `false`, CertCache will use an in-memory token cache to prevent ex |
|
|
|
|
|
Other options from the NPM [redis](https://www.npmjs.com/package/redis#options-object-properties) module can also be used.
|
|
|
|
|
|
### `revoker` Configuration
|
|
|
### `periodic` Configuration
|
|
|
|
|
|
CertCache runs a `revoker` process to handle delayed / post-dated certificate revocations.
|
|
|
|
|
|
|Key|Value|Description|
|
|
|
|---|-----|-----------|
|
|
|
|interval|900|# of seconds between `revoker` runs|
|
|
|
|interval|900|# of seconds between periodic processor runs|
|
|
|
|unknown_days|7|# of days before newly issued certs (`unknown` status) are marked as `not_ok`|
|
|
|
|compliance_days|10|# of days before non-compliance changes (`not_ok` status) take effect|
|
|
|
|
|
|
Note: compliance updates that set a cert's status to `ok` are processed immediately
|
|
|
|
|
|
Each time the periodic processor runs it
|
|
|
|
|
|
* changes status to `expired` when certs have expired
|
|
|
* applies delayed status changes
|
|
|
* cleans up delayed updates that have been applied
|
|
|
* revokes certs marked for revocation
|
|
|
|
|
|
### `sqs` Configuration
|
|
|
|
... | ... | |