The Certificate Enrollment Policy Web Service (CEP) and the Certificate Enrollment Web Service (CES) were introduced with Windows Server 2008 R2 in order to simplify the request for certificates, especially for devices that were not member of a Active Directory domain.
The “classic” way of requesting a certificate from a Active Directory Enterprise CA involves LDAP and RPC/ DCOM, which was okay in the early days of Active Directory, but today, with a CA as a tier 0 asset, this is some kind of a problem.
Implementing a public key infrastructure (PKI) is a recurring task for me. More and more customers tend to implement a PKI in their environment. Mostly not to increase security, rather then to get rid of browser warnings because of self-signed certificates, to secure intra-org email communication with S/MIME, or to sign Microsoft Office macros.
What is a 2-tier PKI? Why is a multi-tier PKI hierarchy a good idea? Such a hierarchy typically consits of a root Certificate Authority (CA), and an issuing CA.
I’m using Let’s Encrypt certificates for a while now. In the past, I used the standalone plugin (TLS-SNI-01) to get or renew my certificates. But now I switched to the DNS plugin. I run my own name servers with BIND, so it was a very low hanging fruit to get this plugin to work.
To get or renew a certificate, you need to provide some kind of proof that you are requesting the certificate for a domain that is under your control.
