An employee of Trustwave created a CSR to demonstrate a proof of concept of what a managed service customer would experience, and submitted it as a request.
Follow-up question: How did the requestor submit that CSR? For example, did they log in as a 'customer' account and submit that to be associated with the account? Did they have their own account? Something separate?
The CSR was emailed to our validation team. The validation agent logged into our internal certificate issuance system and accessed our test account named "SSL Test" to which he and others have access. The unfortunate naming of the test customer was one source of the confusion for the validation agent in thinking that this led to a not-publicly-trusted certificate.
Follow-up question: Do you have the original CSR?
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
This was received and assigned to a validation agent
The Applicant then informed the validation agent that they would like to update the domain, from the domain originally in the CSR to the domain in the certificate (bdo-aws-lca.bdousa.com)
The Validation Agent updated the request from what was in the CSR to what the applicant requested
Follow-up question: What steps are involved in this? While I can imagine this may be a 'routine' task (since there's no requirement that a CSR include the requested domains), I'm curious to understand what existing controls around this process are.
Validation support personnel have the ability to remove or add any of the domains, including the first one, using a separate internal application prior to validation. There are no specific limitations on this capability internally, beyond the fact that they must have access to the application and a user role that allows them to do certificate request validation.
The Validation agent then indicated in the system that they had confirmed, via phone validation, that the Applicant controlled the domain
The issue was that the Validation Agent believed this exercise was within a test environment, and thus did not practice the existing procedures for updating and validating the domain, correct?
This leads to a few follow-up questions:
What is the user experience for your Applicants to make requests - that is, do they make requests for 'testing' and 'production' using the same accounts and application scenarios?
Making a request for 'testing' in this sort of scenario is not common. Typically requests for certificates for internal use go through the same channel as external customer requests which is our Control Center Portal. Our IT department has a customer account and they use our external site to submit a CSR and validate their domains. The request shows up in a queue for the validation support personnel to perform additional validation based on the type of certificate.
This request did not go through the IT channel. It was requested directly from a different department via email to our validation team. This department has very limited experience dealing with SSL certificates working with our SSL support team. Based on the validation agent’s belief that the "SSL Test" customer was not issuing "real" certificates, and with his specialized access user role of being able to execute manual validations, he was able to complete the validation and issue the certificate.
What is the user experience for your Validation Agents when in 'testing' versus 'production'. That is, do they use a common interface and set of accounts to review requests, and designate which environment should be used then, or do they have separate interfaces and accounts?
Our Validation Agents do not have access to a testing environment. In those occasional situations where a true test certificate is needed beyond our normal Software Development Lifecycle processes, this is handled by engineering or QA.
What artifacts are recorded for when phone validation is performed? Have you ensured these artifacts are consistent for validations that have used this method?
For example, does your validation system show that you made domain lookups to determine the phone number (126.96.36.199.3), your phone/PBX system show your validation agents made calls to those numbers, and the information the validation agent entered is consistent with that?
Have you reviewed all other validations by this agent?
Have you reviewed all other phone validations?
Have you examined whether a 'four-eyes' principle (four-ears?) for validations that require humans in the loop, such as 188.8.131.52.3?
This is the only instance of using 184.108.40.206.3 that has been executed, which is why it caught our attention. There is no automation around this method. The evidence recorded would be manually entered by the individual performing the validation.
The other validation methods we perform (2, 3, 6, and 7) are executed by the system, and the typical workflow is for requests to be made available for our validation agents only after these steps have been completed by the customer working with the automated systems.
Our validation team uses the 4 eyes principle extensively already. This particular case, it was not used as it was believed to be a test scenario. We are examining further implementations based on this incident report.