Ah. Might be easier to just let users mail the CSRs and extract them, then :)
To me, the main utility of RA is to be able to retrieve certs for me or someone else, publish CRLs here, policies etc. So it needs to be two-way. Everything can be scripted, of course. Jan > On 25 Feb 2017, at 20:21, Scott Hardin <[email protected]> wrote: > > 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 ------------------------------------------------------------------------------ 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
