I have a cloudfront distribution in production using a Trusted signer key (defined on the root account).
Since 2021 AWS introduced a new mechanism called Trusted Key groups, where it becomes easier to rotate multiple keys and no longer require root account access.
I would like to start using "Trusted Key groups" for my cloudfront distribution, but would also like to make sure the applications that currently generate the secure urls with the existing Trusted signer key and keypairid keep on working.
I tried importing the existing key into Trusted Key groups, but then it gets a new Keypair ID. It also doesnt seem to be possible to configure cloudfront to accept keys from both mechanism.
Is there a way to switch to Trusted Key groups and still keep the current key working?
Related
I can sign the new (public) key with the old (private) key to securely transfer from one to the other. But far as I can tell, there's nothing stopping anyone who gets the old key from signing a different new key as official, even much later after I've given the old one up.
If I revoke the old private key, nobody can make that bogus signature, which is good. But doesn't revoking a key mean its signature of the new one would be invalidated? (As well as every single signature it's made?)
So someone who knows me as "Alice" would be able to tell I'm the same, even if I'm "Bob." But then they see "Alice"'s revocation, in which case they have to throw all of their knowledge about me away, whether Alice or Bob?
The usual way to deal with this is to use a different key for signing keys and for signing “useful” data.
The data signing key lives on an online server where it's invoked automatically, and thus is at risk of misuse. This key is rotated regularly. In principle, it wouldn't need to be rotated: just revoke it if something bad happens. But in practice revocation is hard: it's often difficult to ensure that every party that relies on the signatures will see the revocation message in a timely way. Expiration ensures that even if a party doesn't see the revocation message, it won't keep accepting compromised signatures for long.
The key signing key lives on an offline server with stringent access control, and since it's a lot better protected, it has a very low risk of being compromised.
A system with keys that sign other keys is called a public key infrastructure. Many systems have multiple levels of signing keys. The best known PKI ecosystem is the one used for HTTPS, with servers having a certificate signed by an intermediate certificate authority, which in turn has a certificate signed by another CA until you reach a root CA. Intermediate CAs are online, but run specialized systems which do nothing but sign certificates. The keys to root CA certificates are split among multiple employees who all get together into a vault with no Internet connection once every few years to generate a new intermediate key.
Running your own CA with OpenSSL is not trivial, but it's doable, and you'll find many tutorials on the web.
Let's say we generate a self-signed certificate for each of our customers. They're used in some part of the package/deploy pipeline and end up on the customer's local computers. They're used to connect to our web services.
Should we commit these certificates to source control? The repository is private and only accessible to coworkers. Should I leave them out for some security reason (even if that's just limiting access in case of accidental exposure, let alone malicious activity)?
If we leave them out, should we generate them as part of the package/deploy pipeline every time? Or stick them in some secure keystore and retrieve them?
This is a situation of trust and exposure. Do you trust those that have access to the repository? Bear in mind that most compromises come from insiders.
My thinking is this:
Don't store the deployed certificates at all. Generate them for those end systems. Sign them by a root certificate.
Configure your produce to trust connections made by certificates signed by that root. This way you can revoke certificates in mass if your root is compromised or selectively revoke endpoint certificates as necessary without revoking everything.
You can have your product reference the certificate from the system's certificate store using any public identifiers but don't store the private key.
Making the private key available should be a final deployment step with as minimal visibility as possible. Make it available to two or three users and use the platform's certificate management mechanisms for tying the public certificate to the private key.
I have a domain network and I also have a server in an office that runs all the time. The Domain has several users that is defined in server. So base on these users I want to create certificates to sign documents for inter organizational purposes.(I don't need the certificates to be registered in third party CA).
What I mean is that I want to create a set of signatures that their public keys are user's username and their private keys are user's password. How can I do that?
All my client's OS are windows 7 and My server is windows 2008.
[Disclosure: I work for CoSign]
I want to create a set of signatures that their public keys are user's username and their private keys are user's password.
Standard digital signatures/certificates don't work like that. -- A certificate's public and private keys are long series of characters. The certificate can and usually does include common identifying information such as the user's name and email. You can use your internal domain name/pw as an authentication system for accessing the cert. That's what CoSign does.
You can have one self-signed certification for your organization and use it to easily create the employee's certs. Then the employees can use their domain names/passwords to sign with their cert.
Your employee's certs are chained to your organizational cert, not to an expensive 3rd party CA. Verification: You can publish your org's cert on your website for others to use to verify your employees' individual certs. Or CoSign can publish it. See verify.arx.com
This is exactly what CoSign customers do and it works well. CoSign acts as a Certificate Authority, automatically creating and managing the certificates for your employees.
The certificates are used to sign documents/PDFs/XML files/etc. The signing process, using the certs, is authorized by the employees using their domain name/pw. The CoSign server auto-synchronizes with Active Directory or LDAP systems to minimize the administrative burden of maintaining the certs.
See www.arx.com or contact sales#arx.com for more. Tell them Larry sent you.
I'm attempting to enable SSL communication from a web service client (Axis2) using the certificate on the user's CAC card. Works like a charm....UNTIL the web server is CAC enabled. At that point the SSL connection is rejected with the error message that the other certificates in the chain were not included.
I have ensured that the provider is available, either by adding it to the security.properties file or creating it programatically.
My current approach is to simply set the system properties:
System.setProperty("javax.net.ssl.keyStore", "NONE");
System.setProperty("javax.net.ssl.keyStoreType", "PKCS11");
I understand from this question/answer that this approach only sends the "end entity" certificate. Apparently I need to implement my own X509KeyManager. This is new ground for me, can anyone suggest a good reference or provide samples of how to do so?
Appreciate the assistance.
The best key manager implementation depends on the issuer of the certificates you expect to be using.
If the certificate on the user's CAC will always be issued by a specific CA, simply store that issuer's certificate and any intermediate certificates further up the chain in a PKCS #7 file. In the getCertificateChain() method, this collection can be appended blindly to the user's certificate and returned.
If things aren't quite that simple, but a complete list of possible issuers can be enumerated, obtain all of their certificates, and their issuer's certificates, and so on, up to the root certificates.
Add all of the root certificates to a key store as trusted entries. Bundle the intermediate certificates in a PKCS-#7–format file.
Implement X509KeyManager (or extend X509ExtendedKeyManager if you're working with SSLEngine). Specifically, in the getCertificateChain() method, you'll use a CertPathBuilder to create a valid chain from the user's certificate to a trusted root. The target is the certificate that you load from the user's CAC with the alias parameter. The trusted roots are the certificates in trust store that you created; the intermediate certificates can be loaded from the PKCS #7 file and added to the builder parameters. Once the chain is built, get the certificate path and convert it to an array. This is the result of the getCertificateChain() method.
If you can't predict who will be issuing the user's certificate, you might be able to obtain the intermediate certificates at runtime from an LDAP directory or other repository. That's a whole new level of difficulty.
Looking for some advice about the use of client certs to retro-fit access control to an existing app.
Our company has an existing intranet app (classic ASP/IIS) which we licence to others. Up till now it's been hosted within each organisation that used it and the security consisted of "if you're able to access the intranet you're able the access the application".
I'm now looking for a way to host this app externally so that other organisations who don't wish to host it themselves can use it (each new client would have their own installation).
All user in the new organisation would have a client cert so what I'd like to do is use the 'Require Client Certificate' stuff in IIS. It allows you to say "if Organisation=BigClientX then pretend they're local userY".
What I would prefer is something that says "if Organisation=BigClientX then let them access resources in virtualdirectoryZ otherwise ignore them".
I would be very happy to buy an addon (perhaps an ISAPI filter ?) which would do this for me if that was the best approach. Any advice / war stories would be welcomed.
You likely want to do this. client certs are really intended for a second factor of authentication, but not the primary source. To say it differently, you still need to configure your app for basic or forms authentication.
The technology behind public/private keys is rock solid. However, you need a very mature IT organization who is dealing with certificate lifecycle management. If you do not have this, you will get untold failure scenarios because the certificate was expired, wasn't copied to the new computer, etc.
This is especially true in your scenario where your application is internet facing (in thee 'hosted' scenario) - you have little control about the issuance of the certificates to your users.
I've done something similar...
Generate the certificates internally from your org's domain controller. Export them both as PFX format for distribution, and CER format for you to import in IIS.
Distribute the PFX format exports along with the CA certificate for your DC, so your customers machines will "trust" your CA.
Now in the app properties IIS, go to the Directory Security tab, and under "Secure Communications" click "Edit". In there, click "Accept client certificates", "Enable Client Certificate Mapping", then "Edit".
Under the 1-to-1 tab, click "Add" and import the CER file. Enter the account you'd like to map this certificate to.
As for the "let them access resources" I'd advise doing that by the user account they're mapped through - that is, you can provide access to resources based on that account either through NTFS permissions, or through code by identifying the security context of the logged-in user.