This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 55 lines
!!! Overview
[{$pagename}] ([ACME]) is an evolving [Internet Draft]
Certificates in the Web's [X.509] [PKI] ([PKIX]) are used for a number of purposes, the most significant of which is the [authentication] of [DNS Domain]. Thus, [Certificate Authorities|Certificate Authority] in the Web [PKI] are trusted to verify that an applicant for a [certificate] legitimately represents the [DNS Domain] name(s) in the [certificate]. Today, this verification is done through a collection of [Ad Hoc] mechanisms. [{$pagename}] describes a [protocol] that a [Certificate Authority] (CA) and an applicant can use to automate the process of verification and [Certificate Request Process]. The [protocol] also provides facilities for other [certificate] management functions, such as [certificate Revocation].
* [Certbot] is an [implementation] of an [{$pagename}] [client].
* [Let's Encrypt|Lets encrypt] uses [Boulder] which is an [implementation] of an [ACME]-based [Certificate Authority]
!! Introduction
[Certificates] in the Web [PKI] are most commonly used to [authenticate] [DNS Domain] names.
Thus, [certificate authorities|Certificate Authority] in the Web [PKI] are trusted to verify that an applicant for a [certificate] legitimately represents the [DNS Domain] name(s) in the [certificate].
Existing Web [PKI] [certificate authorities|Certificate Authority] tend to run on a set of [Ad Hoc] [protocols] for [certificate] issuance and [identity Proofing]. A typical user experience is something like:
* Generate a [PKCS10] [RFC 2314] [Certificate Signing Request] ([CSR]).
* Cut-and-paste the [CSR] into a [Certificate Authority] web page.
* Prove ownership of the domain by one of the following methods:
** Put a CA-provided challenge at a specific place on the web server.
** Put a CA-provided challenge at a DNS location corresponding to the target domain.
** eceive CA challenge at a (hopefully) administrator-controlled e-mail address corresponding to the domain and then respond to it on the CA's web page.
* Download the issued certificate and install it on their Web Server.
With the exception of the [Certificate Signing Request] itself and the [certificates] that are issued, these are all completely [Ad Hoc] procedures and are accomplished by getting the human user to follow interactive natural-language instructions from the [CA] rather than by [machine-to-machine] [protocols]. In many cases, the instructions are difficult to follow and cause significant confusion. Informal usability tests by the authors indicate that webmasters often need 1-3 hours to obtain and install a [certificate] for a [DNS Domain]. Even in the best case, the lack of published, standardized mechanisms presents an obstacle to the wide deployment of [HTTPS] and other [PKIX]-dependent systems because it inhibits mechanization of tasks related to certificate issuance, deployment, and revocation.
[{$pagename}] describes an extensible framework for automating the issuance and [DNS Domain] validation procedure, thereby allowing servers and infrastructural software to obtain [certificates] without user interaction. Use of this [protocol] should radically simplify the deployment of [HTTPS] and the practicality of PKIX [authentication] for other protocols based on [TLS].
!! [{$pagename}] on [Github|https://github.com/ietf-wg-acme/acme|target='_blank']
Has the working area for the Working Group internet-draft, "[{$pagename}] ([ACME])" with supporting code.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Automated Certificate Management Environment (acme)|https://datatracker.ietf.org/wg/acme/documents/|target='_blank'] - based on information obtained 2018-07-22-