This repository has been archived by the owner on Aug 30, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 24
iam 3.3 server certs spec
chris grzegorczyk edited this page Mar 27, 2013
·
1 revision
Supporting SSL for ELB instances [1] [2] [3] [4] implies having:
- The ability to provide the system w/ (1) the certificate, (2) the private key, (3) the trust chain [9]
- Policy for storing the private key securely.
- Enabling secure access/transfer of the private key to the
- Key length: 1024, 2048-bit and 4096-bit encryption.
- Keys, Certificates, and Trust Chain must in PEM format.
- Certificates must follow the X.509 PEM format.
- The current date must be between the certificate’s start and end date.
- Public and private certificate files must contain only a single certificate.
- The private key must match the public key that is in the digital server certificate.
- The private key must be an RSA private key in PEM format, where the PEM header is BEGIN RSA PRIVATE KEY and the footer is END RSA PRIVATE KEY (as shown in Sample Certificates).
- The private key cannot be encrypted with a password.
- A certificate chain starts with the immediate signing certificate and is then followed by any intermediaries in order. Intermediaries that are not involved in the trust path must not be included. The trusted root certificate can be optionally included as the last certificate.
- Names of server certificates must be alphanumeric, including the following common characters: plus (+), equal (=), comma (,), period (.), at (@), and dash (-).
Private key is a secret token and should be treated as such.
- Access to a private key should be restricted to those who "need to know"
- A private key should not be sent over the wire or, if it cannot be avoided, only be sent in an encrypted form
- A private key should only be communicated to a trusted/authenticated party
- when stored in the eucalyptus database, a private key should be encrypted with the owning component's key (i.e., EUARE's key)
TODO: Requirements for transferring private keys to LB VMs
Possible scenarios:
- sending the key over the metadata service
- cons: how to do it securely?
- injecting the key using the CLC -> CC -> NC communication path
- cons: the server key might need to be updated at runtime
- pros: explores existing trust relation in the system
- communicating the key using internal LB-to-ELB API
- cons: temprorary credentials are distributed to LBs via an insecure channel (metadata service), so they should not be used to give access to a data with a higher sensitivity level like server certs, which are external to Eucalyptus and generally have a longer lifetime than a load balancer
TODO: Review & Summarize reference [5]
TODO: Review & Summarize reference [6]
TODO: Review & Summarize reference [7] [2]
TODO: Review & Summarize reference [4]
TODO: Review & Summarize reference [8]
TODO: Review & Summarize reference [8]
TODO: Review & Summarize reference [8]
TODO: Review & Summarize reference [8]
- ^ http://docs.aws.amazon.com/ElasticLoadBalancing/latest/APIReference/API_SetLoadBalancerListenerSSLCertificate.html
- a b http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/creating_lb_QueryAPI.html
- ^ http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/US_SettingUpLoadBalancerHTTPS.html
- a b http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/US_UpdatingLoadBalancerSSL.html
- ^ http://docs.aws.amazon.com/IAM/latest/CLIReference/servercertgetattributes.html
- ^ http://docs.aws.amazon.com/IAM/latest/APIReference/API_UploadServerCertificate.html
- ^
- a b c d http://docs.aws.amazon.com/ElasticLoadBalancing/latest/APIReference/API_DescribeLoadBalancerPolicies.html
tag:rls-3.3