Hi Jan, Just to be clear, it's not an "external RA capability". It's just a simple CGI script based on Mojolicious and presents the user with an "upload" form. On issuance, the requester gets a notification e-mail containing a link with the certificate ID. The user authentication/authorization is handled by the apache server itself.
Take a look in the openxpi git repo in clients/perl/OpenXPKI-Client-Enrollment. It's just a proof-of-concept and I got a little carried away with the config options, so it's kinda ugly at the moment. Now that we've added an SCEP library to openxpki, I plan on refactoring the code to drastically simplify things eventually. Best regards, Scott > On Feb 25, 2017, at 19:35, Jan Schermer <[email protected]> wrote: > > Thank you both for answers! > > Scott, are you able to share that frontend? I also think this would be a > worthwile feature to merge - AFAIK no other (free) PKI solution has external > RA capability. Dogtag used to, and it supposedly still somewhat works with > newer CA versions (if you had the old RA installed from before), but they > dropped this feature. EJBCA made it a paid featur. Not sure what other PKI > solutions are there worth trying. Of course it's possible to code a web > frontend, but a proper one with notifications and approvals on the backend is > a bit harder (though it looks like openxpki makes it much easier :)). > > Btw I tried installing OpenXPKI on Ubuntu Xenial and the packages still don't > work (looks like there's a ticket for that), but building from source seems > to work quite well, so I'd just delete the non-working packages for now - > building was much easier than installing them anyway :) > > Jan > > > > >> On 25 Feb 2017, at 17:41, Scott Hardin <[email protected]> wrote: >> >> Hi Jan, >> >> We also have a separate web front end specifically for uploading CSRs and >> downloading the resulting Certificate, with no other certificate management >> functionality whatsoever. It communicates to the backend PKI via SCEP and >> was designed specifically to be used on a bastion host. >> >> Best regards, >> >> Scott >> >>> On Feb 25, 2017, at 17:36, Oliver Welter <[email protected]> wrote: >>> >>> Hi Jan, >>> >>> Am 25.02.2017 um 00:46 schrieb Jan Schermer: >>>> Hi, >>>> I am working on a setup of company CA and I have some questions before I >>>> try setting up openxpki (Disclaimer: I just read through the docs). >>> Thats a good staring point ;) >>> >>>> Thus I'd like to be able to have the CA online and running behind a >>>> firewall, not visible to the public, reaching out to an external RA for >>>> requests >>>> >>>> - CSRs, SCEP requests and any other public interface (OCSP) should be >>>> on an external machine >>>> I don't care much about SCEP, but I want to give the users some >>>> sort of an interface. >>>> I very much like how EJBCA does it - after signing is approved >>>> on the CA, the certificate gets pushed to the RA, notifications are sent >>>> and the user can retrieve the cert without further CA operator involvement. >>>> >>>> - That machine will never connect to the CA itself, but the CA will >>>> rather connect to it and gather requests. This is as closed to air-gapped >>>> setup as I feel is practical. >>>> >>>> Is this possible? If not, is it easy enough to implement? >>>> I can imagine a simple cron job INSERTing the requests into database and >>>> exporting finished certs, but it still needs some sort of a public >>>> interface... (Like a second OpenXPKI instance with deleted private keys?) >>> >>> Ready to use - no, possible - yes, easy to implement - depends... >>> >>> I see three options how to do that: >>> >>> Shared Database: If you can accept a shared database, you can modifiy the >>> default csr workflows so the RA side stops when it comes to signing and a >>> scheduler on the CA side takes over. >>> >>> NICE Interface: The "NICE" interface was made to encapsulate the CA key >>> operations to be sort of atomic. You can build your own instance of this >>> interface that writes the CSR to disk and polls for the certificate (See >>> OpenXPKI::Server::NICE::Local). >>> >>> Custom Workflow: Write your own workflow that dumps the required data to >>> the filesystem, depending on your exact needs it might be necessary that >>> the existing classes need to be extended. >>> >>> There is unfortunately not much documentation around, but examining the >>> existing workflows and reading the perldoc of the classes should give you >>> an idea. >>> >>> best regards >>> >>> Oliver >>> >>> -- >>> Protect your environment - close windows and adopt a penguin! >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! >>> http://sdm.link/slashdot_______________________________________________ >>> OpenXPKI-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/openxpki-users >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> OpenXPKI-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/openxpki-users > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
