My organization is working on a FedRAMP certification and we are struggling to get authorization for our Let's Encrypt certificates due to lack of clarity on how FIPS is enabled on the HSMs. Specifically, our auditors need to know the following information:
The Let’s Encrypt site states that they are using the Thales Luna HSMs.
Can you confirm which of the Thales devices are in use (e.g. Thales Luna K7 Cryptographic Module or ProtectServer PCIe HSM 3 or something else)?
Are all Let’s Encrypt certificates generated from the Luna HSM?
If not, is there a way to obtain certificates generated from the validated HSM?
Can you confirm the Hardware version of the Luna HSM in use (e.g. via hsm showinfo)?
Is FIPS mode enabled for the HSM(requires that HSM Policy (55), “Enable Restricted Restore” is enabled)?
This topic is related to another that we logged on 11/1/2023: Topic 207633
All Let's Encrypt CA Keys (both root and intermediate) are required to be stored solely on (and therefore, can only issue certificates from) FIPS-140-2 level 3 validated HSMs. This requirement is audited by the "WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security - Version 2.6", which can be accessed from this page; you can see the requirement on Page 24, Principle 3, Criterion #11. In turn, Let's Encrypt is audited according to those criteria, and the most recent audit report can be accessed from this page. (Note that, as discussed in the other thread, the requirement does specifically contain the word "validated".) We would not be passing that audit if any of our keys were stored, or any of our certificate issuance was occurring, anywhere other than on a FIPS-140-2 level 3 (or better) HSM.
This should provide enough information to satisfy the auditors. Specifically, it directly addresses questions 2 (yes), 3 (N/A), and 5 (yes), and makes questions 1 and 4 irrelevant. If it does not, please provide additional information regarding why the auditors believe the WebTrust audit regime is insufficient for their purposes.
For what it's worth, https://cloud.gov/ is FedRAMP Moderate and its cert is from Let's Encrypt. They did not use any non-public data for their authorization process, either.
Thank you for these replies. I have provided these audit reports previously and was told it was insufficient. The attestation in your statement that all certs are created on these HSMs may help. I have provided this to the auditor and am awaiting a reply.
They indicated that the report alone, even combined with the documentation we had previous found (see prior linked discussion) around the HSM does not demonstrate that the certificates were issue on a compliant FIPs module. They indicated that given the type of data we process in the environment there is a very specific set of checks they need to follow that allows them to validate the encryption through all points of certificate generation and deployment. Without being able to confirm which specific module is in use and tie that back to the generated cert they could not complete that validation process. The questions above in the initial post came directly from our auditor. I shared the responses on this thread with them and they are reviewing again.
Of note is that in addition to FedRAMP we are working an Information Level ATO so there is some additional scrutiny involved. Regarding the nod to the cloud.gov site which uses these certs they pointed out that public facing websites with public levels of information are not held to the same encryption standards. We have also pointed out that most government sites utilize Let's Encrypt as their certificate of choice.
I wonder the same thing. We looked at moving to another provider but even known players in this industry like DigiCert provide the same level of attestation. I think with theirs you specifically request certs created on government compatible HSMs where Let's Encrypt seems to provide that by default. We have been pushing back because I believe these certificates ARE sufficient, we have just been struggling to get the information presented in a way that proves that belief.
Is it relevant to the conversation? I don't want to throw their name out and have them blacklisted by folks for doing their jobs and attempting to be thorough in their audit investigation (even if we're disagreeing on this specific control).
From what we have been given, the requirement is that they need to be able to map the root certificate back to a validated module listed here Cryptographic Module Validation Program | CSRC.
We must be able to prove that the HSM used to generate the certificate leverages a module listed on that site. That requires three pieces for this scenario;
The Luna HSMs are using a module on that list
The Luna HSMs are configured in FIPS-enforcement mode
The certificates were generated on the HSM with the prior two pieces in place
The audit results should have demonstrated the first two and the note from Aaron above should demonstrate the last. We received pushback originally in accepting the audit attestation as it did not give them the ability to validate that the specific module in use is on the accepted list. As I mentioned, we have brought this back to them one last time with the 3rd piece filled in and we're waiting to see if the trifecta of information can suffice for a level of confidence. I will keep this thread updated with what we find out.
The process we are going through, however, is similar.