New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RFE - provide Enrollment over Secure Transport / EST interface to Dogtag / RFC 7030 to obsolete SCEP #3297

Closed

pki-bot opened this issue Oct 3, 2020 · 1 comment

pki-bot commented Oct 3, 2020

This issue was migrated from Pagure Issue #3180. Originally filed by msauton (@msauton) on 2020-06-22 19:15:16:

Assigned to nobody

RFE - provide Enrollment over Secure Transport / EST interface to Dogtag / RFC 7030 to obsolete SCEP

This is for both RHEL IdM and RHCS, in the pki-core component.

RHEL-8 , Fedora 32+
pki-core-10.x ( 10.8+ ? )

https://bugzilla.redhat.com/1849834

Additional information:

https://github.com/cisco/libest

existing certmonger component bug and ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1841055
https://pagure.io/certmonger/issue/53

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          PKIService: add more general variants of resolveFormat

fe22029

PKIService.resolveFormat is used to check a media type, or list of
media types (possibly including wildcards) against the default list
of content types understood and produced or processed by Dogtag.

The current variants compare the parameter against a hardcoded list
of supported content types.  However, it would be useful to also
provide general variants that allow the caller to specify both the
candidate type(s) and the valid/accepted types.  This commit adds
those variants.

Related: dogtagpki#3297
Signed-off-by: Fraser Tweedale <ftweedal@redhat.com>

frasertweedale mentioned this issue

PKIService: add more general variants of resolveFormat #4046

Merged

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          PKIService: add more general variants of resolveFormat

55c06be

PKIService.resolveFormat is used to check a media type, or list of
media types (possibly including wildcards) against the default list
of content types understood and produced or processed by Dogtag.

The current variants compare the parameter against a hardcoded list
of supported content types.  However, it would be useful to also
provide general variants that allow the caller to specify both the
candidate type(s) and the valid/accepted types.  This commit adds
those variants.

Related: dogtagpki#3297
Signed-off-by: Fraser Tweedale <ftweedal@redhat.com>

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: handle dubious Accept headers

44272b0

At least one EST client is known to send requests with HTTP header
`Accept: text/plain`; see
thales-e-security/estclient#5.

This behaviour is dubious.  It is problematic when communicating
with servers/frameworks that have rigid content negotiation
behaviour (such as JAX-RS).  Nevertheless, the EST protocol uses a
narrow range of media types.  The method and path are sufficient to
determine the request and response media types, regardless of
Content-Type and Accept header values.

To tolerate bogus Accept header values, define and apply a
ContainerRequestFilter that detects when the Accept header does not
match any of the response types used in the EST protocol.  If it
detects this condition it removes the Accept header from the
request.

NOTE: the JAX-RS spec is ambiguous as to whether our use of the API
is legal.  Per the spec,
`ContainerRequestContext.getAcceptableMediaTypes()` returns an
IMMUTABLE `List<MediaType>`.  However,
`ContainerRequestContext.getHeaders()` returns a MUTABLE map of
headers.  We are able to delete the Accept header via that map.  It
seems to be a RestEasy implementation detail that
`getAcceptableMediaTypes()` always reads the Accept header afresh
from the mutable map.

Part of: dogtagpki#3297

frasertweedale mentioned this issue

Enrollment over Secure Transport (EST) service #4047

Merged

6 tasks

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          PKIService: add more general variants of resolveFormat

674f467

PKIService.resolveFormat is used to check a media type, or list of
media types (possibly including wildcards) against the default list
of content types understood and produced or processed by Dogtag.

The current variants compare the parameter against a hardcoded list
of supported content types.  However, it would be useful to also
provide general variants that allow the caller to specify both the
candidate type(s) and the valid/accepted types.  This commit adds
those variants.

Related: dogtagpki#3297
Signed-off-by: Fraser Tweedale <ftweedal@redhat.com>

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: handle dubious Accept headers

f7cc4ff

At least one EST client is known to send requests with HTTP header
`Accept: text/plain`; see
thales-e-security/estclient#5.

This behaviour is dubious.  It is problematic when communicating
with servers/frameworks that have rigid content negotiation
behaviour (such as JAX-RS).  Nevertheless, the EST protocol uses a
narrow range of media types.  The method and path are sufficient to
determine the request and response media types, regardless of
Content-Type and Accept header values.

To tolerate bogus Accept header values, define and apply a
ContainerRequestFilter that detects when the Accept header does not
match any of the response types used in the EST protocol.  If it
detects this condition it removes the Accept header from the
request.

NOTE: the JAX-RS spec is ambiguous as to whether our use of the API
is legal.  Per the spec,
`ContainerRequestContext.getAcceptableMediaTypes()` returns an
IMMUTABLE `List<MediaType>`.  However,
`ContainerRequestContext.getHeaders()` returns a MUTABLE map of
headers.  We are able to delete the Accept header via that map.  It
seems to be a RestEasy implementation detail that
`getAcceptableMediaTypes()` always reads the Accept header afresh
from the mutable map.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          PKIService: add more general variants of resolveFormat

0d8a049

PKIService.resolveFormat is used to check a media type, or list of
media types (possibly including wildcards) against the default list
of content types understood and produced or processed by Dogtag.

The current variants compare the parameter against a hardcoded list
of supported content types.  However, it would be useful to also
provide general variants that allow the caller to specify both the
candidate type(s) and the valid/accepted types.  This commit adds
those variants.

Related: dogtagpki#3297
Signed-off-by: Fraser Tweedale <ftweedal@redhat.com>

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: handle dubious Accept headers

c26beb4

At least one EST client is known to send requests with HTTP header
`Accept: text/plain`; see
thales-e-security/estclient#5.

This behaviour is dubious.  It is problematic when communicating
with servers/frameworks that have rigid content negotiation
behaviour (such as JAX-RS).  Nevertheless, the EST protocol uses a
narrow range of media types.  The method and path are sufficient to
determine the request and response media types, regardless of
Content-Type and Accept header values.

To tolerate bogus Accept header values, define and apply a
ContainerRequestFilter that detects when the Accept header does not
match any of the response types used in the EST protocol.  If it
detects this condition it removes the Accept header from the
request.

NOTE: the JAX-RS spec is ambiguous as to whether our use of the API
is legal.  Per the spec,
`ContainerRequestContext.getAcceptableMediaTypes()` returns an
IMMUTABLE `List<MediaType>`.  However,
`ContainerRequestContext.getHeaders()` returns a MUTABLE map of
headers.  We are able to delete the Accept header via that map.  It
seems to be a RestEasy implementation detail that
`getAcceptableMediaTypes()` always reads the Accept header afresh
from the mutable map.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          PKIService: add more general variants of resolveFormat

199549b

PKIService.resolveFormat is used to check a media type, or list of
media types (possibly including wildcards) against the default list
of content types understood and produced or processed by Dogtag.

The current variants compare the parameter against a hardcoded list
of supported content types.  However, it would be useful to also
provide general variants that allow the caller to specify both the
candidate type(s) and the valid/accepted types.  This commit adds
those variants.

Related: dogtagpki#3297
Signed-off-by: Fraser Tweedale <ftweedal@redhat.com>

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: handle dubious Accept headers

b41a193

At least one EST client is known to send requests with HTTP header
`Accept: text/plain`; see
thales-e-security/estclient#5.

This behaviour is dubious.  It is problematic when communicating
with servers/frameworks that have rigid content negotiation
behaviour (such as JAX-RS).  Nevertheless, the EST protocol uses a
narrow range of media types.  The method and path are sufficient to
determine the request and response media types, regardless of
Content-Type and Accept header values.

To tolerate bogus Accept header values, define and apply a
ContainerRequestFilter that detects when the Accept header does not
match any of the response types used in the EST protocol.  If it
detects this condition it removes the Accept header from the
request.

NOTE: the JAX-RS spec is ambiguous as to whether our use of the API
is legal.  Per the spec,
`ContainerRequestContext.getAcceptableMediaTypes()` returns an
IMMUTABLE `List<MediaType>`.  However,
`ContainerRequestContext.getHeaders()` returns a MUTABLE map of
headers.  We are able to delete the Accept header via that map.  It
seems to be a RestEasy implementation detail that
`getAcceptableMediaTypes()` always reads the Accept header afresh
from the mutable map.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          PKIService: add more general variants of resolveFormat

2a4a7d7

PKIService.resolveFormat is used to check a media type, or list of
media types (possibly including wildcards) against the default list
of content types understood and produced or processed by Dogtag.

The current variants compare the parameter against a hardcoded list
of supported content types.  However, it would be useful to also
provide general variants that allow the caller to specify both the
candidate type(s) and the valid/accepted types.  This commit adds
those variants.

Related: dogtagpki#3297
Signed-off-by: Fraser Tweedale <ftweedal@redhat.com>

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: handle dubious Accept headers

d924a7f

At least one EST client is known to send requests with HTTP header
`Accept: text/plain`; see
thales-e-security/estclient#5.

This behaviour is dubious.  It is problematic when communicating
with servers/frameworks that have rigid content negotiation
behaviour (such as JAX-RS).  Nevertheless, the EST protocol uses a
narrow range of media types.  The method and path are sufficient to
determine the request and response media types, regardless of
Content-Type and Accept header values.

To tolerate bogus Accept header values, define and apply a
ContainerRequestFilter that detects when the Accept header does not
match any of the response types used in the EST protocol.  If it
detects this condition it removes the Accept header from the
request.

NOTE: the JAX-RS spec is ambiguous as to whether our use of the API
is legal.  Per the spec,
`ContainerRequestContext.getAcceptableMediaTypes()` returns an
IMMUTABLE `List<MediaType>`.  However,
`ContainerRequestContext.getHeaders()` returns a MUTABLE map of
headers.  We are able to delete the Accept header via that map.  It
seems to be a RestEasy implementation detail that
`getAcceptableMediaTypes()` always reads the Accept header afresh
from the mutable map.

Part of: dogtagpki#3297

frasertweedale added a commit that referenced this issue


          PKIService: add more general variants of resolveFormat

5bc2aca

PKIService.resolveFormat is used to check a media type, or list of
media types (possibly including wildcards) against the default list
of content types understood and produced or processed by Dogtag.

The current variants compare the parameter against a hardcoded list
of supported content types.  However, it would be useful to also
provide general variants that allow the caller to specify both the
candidate type(s) and the valid/accepted types.  This commit adds
those variants.

Related: #3297
Signed-off-by: Fraser Tweedale <ftweedal@redhat.com>

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: handle dubious Accept headers

8c9b5da

At least one EST client is known to send requests with HTTP header
`Accept: text/plain`; see
thales-e-security/estclient#5.

This behaviour is dubious.  It is problematic when communicating
with servers/frameworks that have rigid content negotiation
behaviour (such as JAX-RS).  Nevertheless, the EST protocol uses a
narrow range of media types.  The method and path are sufficient to
determine the request and response media types, regardless of
Content-Type and Accept header values.

To tolerate bogus Accept header values, define and apply a
ContainerRequestFilter that detects when the Accept header does not
match any of the response types used in the EST protocol.  If it
detects this condition it removes the Accept header from the
request.

NOTE: the JAX-RS spec is ambiguous as to whether our use of the API
is legal.  Per the spec,
`ContainerRequestContext.getAcceptableMediaTypes()` returns an
IMMUTABLE `List<MediaType>`.  However,
`ContainerRequestContext.getHeaders()` returns a MUTABLE map of
headers.  We are able to delete the Accept header via that map.  It
seems to be a RestEasy implementation detail that
`getAcceptableMediaTypes()` always reads the Accept header afresh
from the mutable map.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: handle dubious Accept headers

15352fd

At least one EST client is known to send requests with HTTP header
`Accept: text/plain`; see
thales-e-security/estclient#5.

This behaviour is dubious.  It is problematic when communicating
with servers/frameworks that have rigid content negotiation
behaviour (such as JAX-RS).  Nevertheless, the EST protocol uses a
narrow range of media types.  The method and path are sufficient to
determine the request and response media types, regardless of
Content-Type and Accept header values.

To tolerate bogus Accept header values, define and apply a
ContainerRequestFilter that detects when the Accept header does not
match any of the response types used in the EST protocol.  If it
detects this condition it removes the Accept header from the
request.

NOTE: the JAX-RS spec is ambiguous as to whether our use of the API
is legal.  Per the spec,
`ContainerRequestContext.getAcceptableMediaTypes()` returns an
IMMUTABLE `List<MediaType>`.  However,
`ContainerRequestContext.getHeaders()` returns a MUTABLE map of
headers.  We are able to delete the Accept header via that map.  It
seems to be a RestEasy implementation detail that
`getAcceptableMediaTypes()` always reads the Accept header afresh
from the mutable map.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: implement backend configuration

63368cc

Read backend configuration from <instance-dir>/est/backend.conf.
This includes the "class" property which specifies the backend
implementation to use.  Other properties are loaded and made
available to the backend implementation.  In this way, different
implementations may recognise or require different configuration
properties.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: implement EST frontend and integrated backend

c522941

Implement the EST service as an integrated part of the CA subsystem.
The various interfaces allow for it to be extracted as a separate
subsystem.  The only "big step" to do that is to implement an
alternative `ESTBackend` (i.e. the bits that actually issue
certificates and retrieve CA certificates)

This is a work in progress with the following caveats:

- No authentication of EST client

- No authorization of enrollment requests

- Hardcoded to use `caIPAserviceCert` profile

- Hardcoded `AuthToken` to issue the certificate as user `ipara`,
  with membership in the `Certificate Management Agents` group.

- Only the `/cacerts` and `/simpleenroll` endpoints have been
  implemented.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: create 'est' subsystem

1ad6759

This commit extracts the EST service as a separate Dogtag subsystem,
called "est".  This commit gets the JAR and RPM building cleanly.
However, the following critical features are still to come:

- An "RA" backend unto the CA subsystem (for cert issuance)
- The ESTApplication class (i.e. the Tomcat application itself)
- Deployment capability (e.g. `pki-server est-deploy` command)

These will be provided in subsequent commits.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: add ESTApplication (servlet application)

d8cd97d

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: implement stub RA backend

afc9814

Implement a stub RA backend that returns 404 (/cacerts) or 500
(/simpleenroll and /simplereenroll).  The behaviour to communicate
with Dogtag CA subsystem will be added in a later commit.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: add pki-server est-* CLI commands (+ man page)

71fe3b6

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: remove ProxyRealm from app Context (temporary?)

fe50e32

ProxyRealm seems to be causing issues (realm is null, resulting in
HTTP status 500).  Not yet sure why this is happening but disable it
for now.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: add RewriteValve to server.xml

4d53715

Add the RewriteValve to the <Host> configuration in server.xml, and
add a rule to send requests for /.well-known/est/... to the EST
service.

The rules are defined in Catalina/localhost/rewrite.config, which is
shipped as part of the pki-server package, rather than pki-est.
This is because the rewrite rules (as required for this application)
are top-level server configuration.  If the EST server is not
deployed, requests for /.well-known/est/... will still be rewritten,
but will result in 404.

This commit DOES NOT provide upgrade scripts to add the RewriteValue
and rewrite.config on existing deployments.  If it is necessary,
this will be added in a subsequent commit.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: map exceptions to proper HTTP responses

419a954

Use PKIExceptionMapper to map the various web application exceptions
to the corresponding HTTP response types.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: handle dubious Accept headers

c0c4c17

At least one EST client is known to send requests with HTTP header
`Accept: text/plain`; see
thales-e-security/estclient#5.

This behaviour is dubious.  It is problematic when communicating
with servers/frameworks that have rigid content negotiation
behaviour (such as JAX-RS).  Nevertheless, the EST protocol uses a
narrow range of media types.  The method and path are sufficient to
determine the request and response media types, regardless of
Content-Type and Accept header values.

To tolerate bogus Accept header values, define and apply a
ContainerRequestFilter that detects when the Accept header does not
match any of the response types used in the EST protocol.  If it
detects this condition it removes the Accept header from the
request.

NOTE: the JAX-RS spec is ambiguous as to whether our use of the API
is legal.  Per the spec,
`ContainerRequestContext.getAcceptableMediaTypes()` returns an
IMMUTABLE `List<MediaType>`.  However,
`ContainerRequestContext.getHeaders()` returns a MUTABLE map of
headers.  We are able to delete the Accept header via that map.  It
seems to be a RestEasy implementation detail that
`getAcceptableMediaTypes()` always reads the Accept header afresh
from the mutable map.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: implement backend configuration

c0b640a

Read backend configuration from <instance-dir>/est/backend.conf.
This includes the "class" property which specifies the backend
implementation to use.  Other properties are loaded and made
available to the backend implementation.  In this way, different
implementations may recognise or require different configuration
properties.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: maintain map of ESTEngine instances

da59cd8

Overwriting the "singleton" ESTEngine.INSTANCE value upon each
instantiation of an ESTInstance is unclean.  It also prevents the
use of multiple EST services within a single Tomcat instance (e.g.
an EST server for multiple DNS domains).

Remove this limitation by maintaining a map of ESTEngine instances
keyed by servlet context path.  The contextInitialized() and
contextDestroyed() event hooks add and remove the current instance
from the map.  The ESTFrontend.getBackend() helper method uses the
application's servlet context path to retrieve the corresponding
ESTEngine instance.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          EST: maintain map of ESTEngine instances

1918dfc

Overwriting the "singleton" ESTEngine.INSTANCE value upon each
instantiation of an ESTInstance is unclean.  It also prevents the
use of multiple EST services within a single Tomcat instance (e.g.
an EST server for multiple DNS domains).

Remove this limitation by maintaining a map of ESTEngine instances
keyed by servlet context path.  The contextInitialized() and
contextDestroyed() event hooks add and remove the current instance
from the map.  The ESTFrontend.getBackend() helper method uses the
application's servlet context path to retrieve the corresponding
ESTEngine instance.

Part of: dogtagpki#3297

frasertweedale added a commit to frasertweedale/pki that referenced this issue


          AuthorityService: recognise .../authorities/host-authority/(chain|cert)

45004e3

The LWCA REST API recognises the special identifier "host-authority"
in the getCA method, as well as as a parameter in some other methods
(e.g. nominating the parent CA when creating a new LWCA).  However,
"host-authority" is not recognised when retrieving the certificate
or certificate chain of a CA.  The following resources respond with
400 Bad Request because "host-authority" is not a UUID:

   /ca/rest/authorities/host-authority/(chain|cert)

Update these resources to recognise "host-authority" as referring to
the primary CA in the instance.

As well as being a general improvement to the API, this work was
undertaken specifically to make cert chain retrieval easier for the
EST service.

Related: dogtagpki#3297

fmarco76 pushed a commit that referenced this issue


          EST: implement /cacerts in Dogtag RA backend

d036907

Implement the /cacerts method in the Dogtag RA backend.

The implementation includes a substantial amount of code to prepare
the configuration for the PKIClient.  Parameters are read from the
ESTBackendConfig following a similar pattern to the ACME PKIIssuer.

The code to actually retrieve the certificate chain from the CA
subsystem is quite succinct.  The AuthorityClient retrieves the
chain as a PEM-encoded PKCS #7 object.  We then parse the response
and extract the certificates.  Nevermind that the EST front-end will
then put those certificates in a new PKCS #7 object and serialise
it.  Fundamentally it is unnecessary work.  But the API is cleaner
and more understandable through the use of proper data types rather
than strings and byte arrays.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: tighten exceptions thrown by ESTBackend

a6efd67

Restrict ESTBackend endpoint methods to throwing PKIException.
PKIExceptionMapper will turn PKIException (and its subclasses) into
proper HTTP responses.

Also remove the ESTEnrollResult class which is no longer required.
Enrollment failure details will be conveyed by throwing a [subclass
of] PKIException.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: extract ServletContextListener

91fa454

The recent commit f4aeb60 extracted
the ServletContextListener implementation from the "engine" class
for each existing subsystem.  This commit does likewise for the EST
subsystem.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: implement /simple[re]enroll in DogtagRABackend

091d8e8

Following the pattern of the ACME PKIIssuer, implement the issuance
behaviour for the EST /simpleenroll and /simplereenroll endpoints.
The RA account credentials are taken from
<subsystem-dir>/backend.conf, for example:

    class=org.dogtagpki.est.DogtagRABackend
    url=https://f36-0.ipa.test:8443
    profile=estServerCert
    username=estra
    password=4me2Test

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: improve logging/reporting of certificate encoding failures

a63460e

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: implement /simplereenroll and labeled enrollment

0e05af4

In ESTFrontend, implement /{label}/simpleenroll, /simplereenroll,
and /{label}/simplereenroll.  Authentication and authorization
remain as TODOs and will be implemented in subsequent commits.

As part of this change, extract the CSR parsing and enrollment
response building to separate static methods.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: tighten ESTBackend interface to JSS X509CertImpl

a289315

The ESTBackend issuing methods currently return a
java.security.cert.X509Certificate.  The ESTFrontend injects the
returned certificate into a JSS CertificateChain object.  Although
that type accepts an X509Certificate, in fact it will throw an
IOException if the value is not a JSS X509CertImpl (which implements
X509Certificate).

To avoid the possibility of a backend implementation returning an
incompatible value, modify the API to explicitly return values of
type X509CertImpl.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: explain the simpleenroll vs simplereenroll correspondence

4dce541

Add some commentary explaining explaining why DogtagRABackend has
the same behaviour for simpleenroll() and simplereenroll().  Or to
look at it another way, why there are two different methods, even
though this backend currently has the same behaviour for both
methods.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: format Content-Type header for libest compatibility

ead3d58

The value of the response Content-Type header is derived from the
"@produces" annotation on the service method.  For example:

    @produces("application/pkcs7-mime; smime-type=certs-only")

The JAX-RS machinery then converts this into a value of type
javax.ws.rs.core.MediaType, and it is set as such in the
response headers (a MultivaluedMap<String, Object>).

When serialising the Response, header values are stringified via
types that implement the  RuntimeDelegate.HeaderDelegate<T>
interface, where T is the real type of the header value Object
(e.g. MediaType).  The HeaderDelegate implementations are
supplied by the JAX-RS implementation.  In our case that's
Resteasy, and the class in question:

    public class MediaTypeHeaderDelegate
        implements RuntimeDelegate.HeaderDelegate<MediaType>;

The toString(MediaType type) method provided by this class
prints the media type WITHOUT a space between the subtype
and the parameters.  In the example from the @produces above,
it results in the header value:

    application/pkcs7-mime;smime-type=certs-only

This is a legal production in the HTTP grammar.  From the RFCs
7230 and 7231:

    media-type = type "/" subtype *( OWS ";" OWS parameter )
    OWS = *( SP / HTAB )

However, at least one EST client is unable to process this
value.  libest expects a SPACE after the ';'.  From
src/est/est_client_http.c:

    ...
    } else if (!strncmp(ct, "application/pkcs7-mime; smime-type=certs-only", 45)) {
    ...

The string libest expects is also a valid production.  But it is
not the one being sent from Tomcat/Resteasy.  As a consequence,
the enrollment operation fails.

To make our EST implementation compatible with libest, we need to
override how the MediaType gets stringified.  I was unable to
find a way in the JAX-RS to override the HeaderDelegate.  But we
can solve it in a case-by-case way via this response filter.

At the time response filters are applied, the Content-Type header
value is an object of type MediaType.  If the value is equal
(including parameters) to a value whose serialisation we need
to precisely control, we replace it with the exact String
required.  The String value will be used in the response "as is".
These substitutions are stored in a Map generated from the list
of all verbatim target headers.

If it emerges that different stringifications of the same
MediaType value are required for different client
implementations, we could inspect the request User-Agent header
to further refine the behaviour.  We could, for example, create a
Map for each User-Agent that requires header substitutions, or
change the key of the map to the User-Agent×MediaType pair.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: support issuing from specified LWCA

83dee12

Update the DogtagRABackend to interpret the {label} path component,
if given, as an AuthorityID.  Issue the request to the nominated
authority (a.k.a. lightweight CA / LWCA).

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: require authenticated user for enrollment

2f9fc3e

Add security contraints to require an authenticated user for
enrollment requests.

This is implemented by requiring an authenticated user for all POST
requests.  It would have been preferable to use paths; unfortunately
we cannot.  In EST, paths such as
`.well-known/est/{label}/simpleenroll` are used, where {label} is
user-specified and interpreted by the server.  But Servlet
<url-pattern> can only match path prefixes.

So far, the set of resources we have implemented are such that all
POST requests require authentication, and all GET requests are
anonymous.  If this changes in the future, we will have to move
authentication down into the application itself.

The valid role name is "**" meaning any authenticated user will be
granted access.  The EST application performs its own authorization
checks (to be implemented in a subsequent commit).

The realm configuration is also left to the administator.  Future
commits may deal with providing alternative means of realm
configuration.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: add authorization interface

b34386a

Add the EST authorization interface.  Design sketch:

- abstract class ESTRequestAuthorizer defines the authorization
  interface.  Each enrollment method (currently: simpleenroll and
  simplereenroll) has its own authorization method.

- The arguments of the authorization methods are an
  ESTRequestAuthorizationData and the CSR.

- ESTRequestAuthorizationData contains common data used for making
  authorization decisions, including:

  - authenticated principal
  - client IP address
  - EST path label (if any)

- ESTEngine instantiates and initializes a concrete subclasses of
  ESTRequestAuthorizer according to configuration.

- ESTFrontend enrollment methods construct the
  ESTRequestAuthorization data, accesses the ESTRequestAuthorizer
  via the ESTEngine and invokes the relevant authorization method.

- (Next commit) ESTFrontend passes the Object returned by the
  authorization method to the ESTBackend enrollment method.  In this
  way, arbitrary data generated by the authorizer implementation can
  be consumed by the ESTBackend implementation.

Subsequent commits will implement the authorization result Object
propagation, and provide an authorizer implementation that invokes
an external process to compute the authorization result.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: propagate authorizer output to backend

ebbb4aa

Propagate the output of the ESTRequestAuthorizer authorization
method to the ESTBackend issuance method.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: implement ExternalProcessRequestAuthorizer

914a86b

Implement the ExternalProcessRequestAuthorizer.  This implementation
executes the configured executable as a subprocess.  It pipes the
request authz data, CSR and label to the subprocess standard input
as a JSON object.  The request is authorized if the subprocess exits
normally (exit status 0).  If the subprocess does get created but
exits abnormally, throws ForbiddenException using the subprocess
standard output as the message.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: provide client cert in request authz data

5d9e4e7

When the EST client uses TLS client certificate authentication,
provide the client certificate chain in the
ESTRequestAuthorizationData.

Also update the ExternalProcessRequestAuthorizer to put the
certificate chain in the JSON object provided to the subprocess
standard input.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: fix some incorrect visibilities

e6b842a

Some classes and fields had unsuitable visibility, which this commit
addresses.  Specifically:

- The `ESTBackend` `config` field had default (package) visibility,
  but needs to be visible to subclasses (which may be implemented by
  anyone).  Make it `protected`.

- The `ESTRequestAuthorizationData` class had default (package)
  visibility, but it needs to be visible to arbitrary subclasses of
  `ESTRequestAuthorizer`.  Make it `public`.

- The fields of `ESTRequestAuthorizationData` had default (package)
  visibility.  Make them `public` so as to be readable by arbitrary
  subclasses of `ESTRequestAuthorizer`.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: set up rewrite.config when using pki-server create

f18fba8

When deploying via `pki-server create`, we fail to install the
`rewrite.config`.  Add this behaviour.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: add RewriteValve to server.xml when using pki-server create

b29cbe5

The `pki-server create` deployment regime copies and modifies
`/etc/tomcat/server.xml`, rather than copying the `server.xml`
shipped in the pki-server package.  This `server.xml` does not
include the RewriteValve, which we use to rewrite requests
`/.well-known/est` to the actual application path.

Update the deployment procedure to add RewriteValve to `<Host>`
elements in the `server.xml`.  The behaviour is encapsulated in the
`add_rewrite_valve(document)` staticmethod.  The operation is
idempotent - a no-op if RewriteValve is already present.  Therefore
this method may be useful in upgrade scripts too.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: treat backend authnz failure as internal error

1a7585b

DogtagRABackend re-raises PKIException thrown by the CAClient.  If
something is misconfigured resulting in the CA subsystem responding
401 or 403, the EST responds the same way.  This is a bug.

Modify DogtagRABackend to inspect the int code of the caught
PKIException.  If  401 or 403, throw a new PKIException (status
500).  Otherwise re-raise, as previously.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: compare CSR Subject and SAN to cert being renewed

0032b8d

RFC 7030 Section 4.2.2. "Simple Re-enrollment of Clients" states:

  A certificate request employs the same format as the "simpleenroll"
  request, using the same HTTP content-type.  The request Subject field
  and SubjectAltName extension MUST be identical to the corresponding
  fields in the certificate being renewed/rekeyed.

Implement this requirement.

Note that we really do check that the values are __identical__, by
comparing their DER.  StringPrep, caseIgnoreMatch and GeneralName
type-specific equality rules are not applied.  Nor do we consider
that equivalent SAN values could appear in different orders.

So, we indeed implement the RFC correctly.  But we should not be
surprised if this turns out to be too strict.  Real world scenarios
could necessitate relaxing the check from "identical" to
"equivalent".  But for now, we stay with the strict - and much
simpler! - behaviour.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: pkispawn: handle already-existing rewrite.config

1bb2c8f

Some deployment scenarios involve using `pki-server create` and then
running `pkispawn`.  For example, you can explicitly create the
server instance and NSSDB, then install the CA with the existing
database.

Such a scenario currently fails because both steps try to create the
`rewrite.config` symlink.  pkispawn fails with FileExistsError.
Update the code to gracefully handle this scenario.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: fix build with jackson-2.10

643fdbb

Some platforms we target have jackson-2.10.  Build is failing due to
use of a JsonGenerator method that was only added in v2.11:

    error: no suitable method found for writeArray(String[],int,int)
        generator.writeArray(roles, 0, roles.length);

Update our implementation to avoid use of this method.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: fix build issue with EST on v10.2.1:

82e696e

Building against the older JSS on target platforms for v10.2.1 fails
due to:

    cert.getSubjectName() symbol not found

Instead of porting patch 1ced9c8cf from jss v5 to v4.9.x, replace
`cert.getSubjectName()` with `cert.getSubjectDN()` as a workaround
to allow EST to build against jss v4.9.x.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: convey to-be-renewed cert to authorizer

d044eca

In general (although not in our implementation - yet) the
to-be-renewed certificate is not necessarily the same as the client
certificate used to authenticate.  Add a parameter for the
to-be-renewed certificate to the
`ESTRequestAuthorizer.authorizeSimplereenroll()` method.

Also update the `ExternalProcessRequestAuthorizer` to include the
certificate in the `toBeRenewed` field of the JSON data sent to the
child process.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: enable use of RealmBase realm subclasses

84a3250

Enable the use of "native" Tomcat RealmBase subclasses (e.g.
MemoryRealm) with the EST subsystem.  The main aspects of this
change are:

- Invoke the LifecycleBase start()/stop() methods at the
  corresponding WebListener lifecycle changes.

- Register the realm with ProxyRealm *before* invoking start().
  ProxyRealm.registerRealm() invokes setContainer(), a prerequisite
  for start() to succeed.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: set properties of RealmBase subclass instances

c1435c5

Currently there is no way to configure instances of Tomcat "bundled"
realms.  For trivial implementations like `MemoryRealm` this is not
an issue.  But for other implementations (e.g. `JNDIRealm`,
`JAASRealm`, etc) a configuration mechanism is necessary.

Tomcat's own configuration mechanism uses introspection to propagate
attributes in the XML `<Realm>` element to the new `Realm` object.
It looks for a setter method whose name is the capitalisation of the
attribute name, prepended with `"set"`.

Update `ESTEngine` to do likewise for the properties in
`realm.conf`, when the realm is an instance of `RealmBase`.  The
`IntrospectionUtils.setProperty` helper method from Tomcat does the
heavy lifting.  We just need to iterate the properties and set each
one.

Properties that have no corresponding setter method or which throw
`IllegalArgumentException` result in a `RuntimeException` that
reports the bad property.  This behaviour forces administrators to
resolve or remove bad properties in `realm.conf`.

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: add commentary to example profile config

a9b8391

Part of: #3297

fmarco76 pushed a commit that referenced this issue


          EST: add commentary to example profile config

5b76b8e

Part of: #3297

Contributor

ckelleyRH commented Mar 16, 2023

This RFE is now implemented.

ckelleyRH closed this as completed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment