My team is adding ACME 2.0 client support to the Open Liberty application
server and wanted to test against Dogtag PKI's ACME server. My intention is
to containerize the ACME server and drive it through the same functional
tests we run against other ACME CA servers (i.e. - Pebble and Boulder for
instance) to verify compatibility.
The first error I hit was an issue with using JSS 4.7 and I understand that
will be fixed by PR https://github.com/dogtagpki/jss/pull/532 .
2020-05-04 22:15:53 [http-nio-8080-exec-5] SEVERE: Unable to validate
HTTP-01 challenge: Unable to get SunJSSE provider for TLS:
SSLContextImpl is not initialized
java.lang.RuntimeException: Unable to get SunJSSE provider for TLS:
SSLContextImpl is not initialized
To move past this error, I was advised to move down to JSS 4.6.2. Upon
doing so, I made it past the initial error but now hit the following error:
2020-05-05 18:36:08 [http-nio-8080-exec-7] SEVERE: Servlet.service()
for servlet [Resteasy] in context with path [/acme] threw exception
org.apache.commons.lang.NotImplementedException: Code is not
Caused by: org.apache.commons.lang.NotImplementedException: Code is
I can see in the ACME server's trace that it does indeed authorize my
ownership of the domain and then try to issue the certificate. Examining
the AcmeIssuer class shows that this class has several methods that are not
Is this expected or is it possible I have a misconfiguration? I assume I am
testing too early and need to wait until the implementation is further
along, but I wanted to test early enough that if there were issues I could
detect them earlier rather than later.
If it matters, I am testing the with the image from @pki/master on a Fedora
30 docker container.
Jesse Van Hill
Websphere Identity Management Architect & Dev Lead
WebSphere Application Server & Open Liberty
We discussed the possibility of using Cockpit in Dogtag PKI with our whole
team (including Devs, QEs, CEE, POs and PMs). It seems that the proposed
solutions by Martin and Simon seem to require major architectural changes to
Dogtag PKI product itself, which, as Fraser pointed out, circles back to the
requirement of full-fledged IDM environment.
So, as of now, we have decided to use the PatternFly and ReactJS directly to
design our web interface (to stay as close to the cockpit design as
On Mon, Jun 8, 2020 at 8:36 AM Simon Kobyda <skobyda(a)redhat.com> wrote:
> On Fri, 2020-06-05 at 11:13 +0200, Martin Pitt wrote:
> > Hello Dinesh,
> > Dinesh Prasanth Moluguwan Krishnamoorthy [2020-06-03 20:17 -0400]:
> > > I’m part of Dogtag PKI open-source project . Our team strives to
> > > provide
> > > enterprise-class open-source Public Key Infrastructure (PKI) .
> > FTR, Simon Kobyda (CCed) is working on a Cockpit page for managing
> > certificates
> > . There may be some overlap here, so perhaps you can meet and
> > exchange some
> > ideas.
> This sounds interesting. Is this module of yours (as I guess from email
> subject) mainly oriented for Smart Cards? What use cases does it look
> to solve?
> The module I'm working on is so far oriented about functionalities
> provided by certmonger. It provides UI to functionalities such
> requesting and tracking certificate, importing preexisting certificate
> & key and renewing and resubmiting it.
> It can request certificate from CA configured to certmonger like IPA.
> The module so far doesn't have hard set limitations so it can be
> expanded (for example outside of scope of just certmonger) if we find
> some overlap.
> > > 1. According to  Cockpit seems to require the host to join the
> > > IdM
> > > domain in order to authenticate PKI users into Cockpit using client
> > > cert
> > > auth. Is it possible to use client cert auth without joining a
> > > domain? Will
> > > that require major changes in Cockpit?
> > To be precise, Cockpit calls sssd to map a given certificate from TLS
> > client
> > cert auth to a user , with FindByCertificate().
> > This doesn't *inherently* require IdM. It's just (1) the only way how
> > I got
> > that sssd lookup mechanism to actually work, and (2) it generally
> > makes sense
> > to maintain this cert→user mapping centrally.
> > Allegedly it is possible to configure sssd to do this mapping with
> > local
> > certificates . I played around with that a few weeks ago, as that
> > would be a
> > very interesting use case, but I didn't manage to get it working --
> > apparently
> > the FindByCertificate() sssd method only works with IdM, not with
> > these local
> > certificates. Making that work may be an interesting project.
> > So this all hinges on sssd -- if that can map a certificate, you can
> > log into
> > Cockpit. Cockpit itself would need no modifications for backends
> > other than
> > FreeIPA.
> > > 2. Suppose the user has been authenticated into Cockpit using a
> > > client cert
> > > as described in #1, is it possible for Cockpit to use the same
> > > client
> > > certificate auth to access PKI server? Or do we need to use a
> > > different
> > > auth mechanism?
> > As Fraser already pointed out, cockpit's web server doesn't have the
> > private
> > key that the browser end was using to authenticate, so that doesn't
> > work.
> > Does it have to be TLS client cert auth, or would kerberos work as
> > well? We
> > are currently designing that so that we can "forward" (or rather,
> > convert/transcend) the initial client cert auth to a kerberos ticket,
> > so that
> > cockpit can use that to further authenticate to services like sudo or
> > ssh.
> > Structurally that's very similar, but it would require the PKI server
> > to accept
> > delegated (S4U) kerberos tickets.
> > Martin
> >  https://github.com/skobyda/cockpit-certificates
> > 
> > 
> >  https://projects.engineering.redhat.com/browse/COCKPIT-542 -- RH
> > internal only
> cockpit-devel mailing list -- cockpit-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to cockpit-devel-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: