...
In this case one of the replicas triggers the AAF to create a certificate for the service. This certificate is stored on a shared volume, where other replicas pick-up and use this certificate. According to the creator of AAF Application Config & Cert Documentation (Temporary) this seems to be the prefered preferred way to use the automatic generation of certificates.
Advantages:
- allows manageable certificate management (including revoke), as 1 certificate == 1 service
- does not introduce additional hard dependency of each replica on AAF (all works or all fails)
...
- Unknown security of the shared network volume
- Expiration of certificate affects all replicas
- shared volume needed for each service using automatic certificate generation
- short delay on startup to get certificate from shared network volume (network reliability affects replica startup)
...
- Certificate is not shared on a network volume
- soon to be expired certificates can be renewed by killing the replicasss
- works in environments without shared network volumes (NFS or similar not needed)
Disadvantages:
- Unable to track issued certificates or manage them (e.g. no sensible revoke)
- each replica has a different certificate (not sure if this could be a problem to not)
- harder to track certificates that are due in near future (i.e. no expiration management as replicas come and go in case of dynamic load-balancing for example)
- hard dependency of each new replica on AAF (AAF certmanager will be a bottleneck for service startup)
- longer startup time and resource usage for services (i.e. time to generate certificate and the CPU/Network overhead involved)
Other concerns - how AAF will provide certificate password
Each generated certificate has a password. In order to use the certificate the service/replica needs to know this password. The question is how to make this AAF issued certificate password available to the services in a secure way so they can access their certificate?