Despite the documented shortcomings of the Simple Certificate Enrollment Protocol (SCEP), it is still in widespread use today. This is in large part due to the lack of better options when it comes to certificate enrollment – especially when it comes to more limited devices such as mobile phones, tablets, and constrained Internet-of-Things (IoT) devices such as embedded systems, sensors, automotive components, or medical devices. The simplicity of SCEP makes it an attractive choice for implementers that are bent on meeting tight timelines, but this simplicity can come at a cost.
Among the more glaring problems with SCEP is that it contains no endpoint authentication capability – SCEP quite literally is unaware of the identity of the certificate requestor. This is a significant problem, and makes it almost impossible to properly vet certificate requests.
The lack of requestor identity is only partially mitigated by the addition of an optional one-time Challenge Password which the requestor must supply with each request (alas, with no username). Unfortunately many systems still use SCEP without even the Challenge Password for protection.
Even five years after the initial SCEP vulnerability announcement, some vendors still specifically instruct their customers to turn the passwords off for their SCEP servers – literally disabling the last shred of protection over subscriber vetting. Customers who follow this guidance on SCEP servers that also support enterprise authentication are unknowingly allowing any user to request certificates with any other user’s identity.
CSS has been leading the SCEP-improvement charge for some time, including the creation of a patented approach called VSCEP™ for overlaying identity controls and content verification, and bridging some of the gaps associated with the protocol.
In many cases, SCEP is still the only option. Newer protocols are on the way, though adoption is still slow. In the meantime, the risks associated with SCEP can be mitigated with proper configuration and oversight.