Thursday, February 7, 2019

EJBCA 7.0.0: The Same, but Completely Different

It's not often that we get to celebrate the emergence of a major release of EJBCA, and this has been a long time coming. World, meet EJBCA 7!

So what's new you ask? New workflows? VR based UI? Is everything solved using blockchains, machine learning and quantum cryptography?

Well, we're afraid not. What we actually have done is dug down and replaced nearly all of the backing code for the UI, some of which has been around ever since EJBCA's inception back in 2002. Same old trusty EJBCA, but with a newly furnished engine. While this may sound a bit lackluster at first glance, this is the first major beachhead that will allow the PrimeKey team to start making great strides in improving EJBCA's user experience for our customers and their clients. This is not the end, but the start of an exciting new journey.

Technology Leap to JDK8/JEE7

Probably the most impactful change of upgrading to EJBCA 7 is that we're dropping support of JDK7, and by extension JEE6 reliant application servers. In essence, from here on in that means that the minimum supported application server is JBoss EAP7/Wildfly 10. If your current installation is running on an earlier JDK or application server we recommend upgrading those first, going through an intermediate release of EJBCA if necessary. The EJBCA Upgrade Guide has detailed instructions for which workflow to follow if this applies to you.

This leap is partly motivated by the end of professional support for JDK7 from Oracle coming this summer, but also because it both allows us to upgrade older libraries (which have long since ceased receiving security updates) and to be able to make use of much of the newer technology which has been developed in the intervening years in order to improve your user experience.

JDK11 Support

While not completely tried and tested yet, we've begun implementing support for JDK11, and have it working in our test environment. For production environments, we recommend sticking to JDK8 for the time being, but for the adventurous among you, we would by all means appreciate any feedback.

Roadmap Update

Deprecating the Public Web and slimming down the CA Web UI

As mentioned above, we're heading into an exciting new era for EJBCA. The time has come for us to finally begin deprecating old functionality, and as we have mentioned before, two primary sections are on the chopping block: RA functionality in the CA Web and the Public Web, with the intent of them being fully replaced by the RA Web.

Our goal in the coming months is to replicate the remaining missing features in the RA Web (we're nearly there), and further improve workflows in order to minimize context switching between the UIs, leading to a more natural user experience for EJBCA administrators. Once we feel secure that this is done we're going to perform a soft drop of the pages (hiding them by default, but still making them available if needed) before dropping them entirely in the long term. If your workflows still rely on those two feature sets, we recommend taking a look at the RA Web.

Appliance Release

EJBCA 7 (or a later minor release) will be included in Appliance version 3.3.0 and is scheduled towards the end of Q1.

Mike Agrenius Kushner
Product Owner, EJBCA

Tuesday, November 20, 2018

EJBCA 6.15.1: Publishers, Publishers, Publishers!

    We couldn't stay away, so at the same time as the UI is being refurbished and prepared for our coming Common Criteria certification we've been busy adding some neat new features to EJBCA 6.15: Publishers Galore!

    Multi Group Publishing

     In order to facilitate for users administrating large numbers of publishers referenced in multiple certificate profiles, we've implemented the Multi Group Publisher

    By referencing Multi Group Publishers instead of the affected publishers directly, actions such as adding or removing VAs can quickly permeate throughout all affected certificate profiles. The publisher also allows splitting referenced publishers into groups, which establishes parallel publishing queues. 

    SCP Publishing and VA Population

    Due to popular demand for an alternative to the Peer Publisher in environments where establishing a Peer Connection between CA and VA isn't an option, we've created the SCP Publisher, which publishes certificates and CRLs to a remote location over SCP.

    Conversely, in order to import certificates and CRLs exported by the SCP Publisher a VA, we've implemented the Certificate and CRL Reader Service

    GDPR Adapted Legacy VA Publisher

    Just like we did for the Peer VA Publisher back in EJBCA 6.13, we've GDPR adapted the Legacy VA Publisher.

    By enabling the new Don't store certificate meta data option at the bottom, VA publishing can be performed without writing any identifying information to the VA. 

    Revocation Time added to CertSafe Publisher

    The output of the CertSafe Publisher has been amended to include revocation time. 

    Mike Agrenius Kushner
    Product Owner, EJBCA

    Monday, October 8, 2018

    Keep track of certificate issuance using Graylog (and pretty dashboards)

    Running an EJBCA based PKI can be a very boring task, usually everything just works. One complaint that we get is that it just works so stably, that the operations staff forgets what to be done when something happens.

    Apart from being boring to run, a question that i asked now and then is to get reports or displays of issued certificates, with different flavor sand slices of reporting. As EJBCA is open, you can find all needed information in the database, or in the audit logs. The question is of course how to aggregate information across cluster nodes, and how to process it in a nice way.

    One answer to this is to use a central log system, which can process logs from all nodes in a cluster, or even from different segments, like Issuing CAs, OCSP responders, RAs etc.

    Using the Open Source Log Collection and Analysis tool Graylog, we can do all this. For those familiar with other similar tools such as Splunk, it works quite similarly, and EJBCA users currently successfully use both Splunk and Graylog in production. Some buzzwords for this are Log Aggregation, Central Log Analysis, SIEM, etc.

    So what can it look like?
    Example EJBCA Dashbord on Graylog

    A Little Background on Logs

    An EJBCA PKI system has the following types of logs:
    • Security Audit Log: Used for PKI auditors to audit important security PKI events that the system performs.
    • System Log: Used to monitor daily operations in the system, debug and track down errors etc.
    • Transaction Log: Used for accounting of specific functions, mainly validation (OCSP).
    The Security Audit Log constrains greatly what it logs (defined by EJBCA's Security Target), and does not log any other events. Events pertinent to log are ones such as "Certificate issued", "Certificate Profile edited", "Administrator accessed resource", etc. One of the most important aspects to consider is that the Security Audit log does not log things that do not happen. Things that do not happen are for example invalid requests that the system rejects, because the PKI system did not perform any important auditable event.

    The System Log, on the other hand, logs all events that are interesting to monitor, such as rejecting invalid requests, reading profiles etc.

    Full information of EJBCA logging can be found in the documentation.

    Integrating with Graylog

    The easiest integration, that I found, was to simply send logs using Syslog from EJBCA to Graylog. Assuming you have EJBCA running, and Graylog running (I used the AWS AMI to get up and running in no-time) it is easy to start sending logs to Graylog.

    Configuring Syslog Sending and Receiving

    I used Syslog-TCP, which is not enabled by default in Graylog, nor in JBoss/WildFly (where EJBCA runs).

    Enabling Syslog TCP Input in Graylog

    To enable using syslog TCP input in Graylog, do the following:
    1. Go to the Graylog Web Console and select System > Input.
    2. Select Syslog TCP in the Select Input list menu and click Launch new input.

    Configuring EJBCA Logging

    On the EJBCA server, configure JBoss/WildFly to send messages to Graylog with syslog TCP. This is done by adding the following section in the logging subsystem in the JBoss/WildFly standalone.xml:

    <custom-handler name="SYSLOGTCP" class="org.jboss.logmanager.handlers.SyslogHandler" module="org.jboss.logmanager">
        <level name="INFO"/>
        <encoding value="ISO-8859-1"/>
            <pattern-formatter pattern="%-5p [%c] (%t) %s%E%n"/>
          <property name="appName" value="WildFly"/>
          <property name="facility" value="LOCAL_USE_5"/>
          <property name="serverHostname" value=""/>
          <property name="hostname" value="-"/>
          <property name="port" value="514"/>
          <property name="syslogType" value="RFC5424"/>
          <property name="protocol" value="TCP"/>
          <property name="messageDelimiter" value="-"/>
          <property name="useMessageDelimiter" value="true"/>

    You also need to configure the root-logger to use the new handler, this will start sending the same logs to syslog. Add the new handler by modifying the root-loggers section in standalone.xml:

        <level name="INFO"/>
            <handler name="CONSOLE"/>
            <handler name="FILE"/>
            <handler name="SYSLOGTCP"/>

    Send some log items by performing an action in the EJBCA Admin UI, for example saving a certificate profile.

    Configuring Graylog

    Configuring Graylog involves a few tasks:
    • Creating Exctractors
    • Making some Searches
    • Adding searches to a Dashboard

    Create Graylog Extractors

    Graylog Extractors are used to extract fields, that can be used in queries in Graylog, from the log stream. You can create Extractors for your log input under System > Input in the Graylog Web Console.
    You can analyze log items and create the extractors you need. In our example, the following extractors are created:
    • RADN: An administrators DN who issued a certificate, for example 'CN=RA Admin,O=PrimeKey,C=SE'
      • Extractor type: Split & Index
      • Split by: ;
      • Target index: 6
    • EVENT: The event that happened, for example 'CERT_CREATION'
      • Extractor type: Split & Index
      • Split by: ;
      • Target index: 2
    • CERTPROFILE: the certificate profile a certificate was issued for, for example 'certprofile=346136222'
      • Extractor type: Split & Index
      • Split by: ;
      • Target index: 11
    You can edit and create extractors of many different types, the above are simple examples.

    After the extractors have been created, go to EJBCA and make some actions, to log something you want to visualize. Such as running a stresstest to issue a bunch of certificate, by different RAs.

    Add and Visualize Searches on a Dashboard

    The following provides examples of search result information that you can add to your dashboard.

    Examples of search result information to visualize:
    • CERT_CREATION last day
      • Search in the last 1 day
      • Click Add count to dashboard
    • CERT_REVOKED last day
      • Search in the last 1 day
      • Click Add count to dashboard
    • Certs issued by SuperAdmin all time
      • Search in all messages
      • Click Add count to dashboard
    • Certs per RA
      • Search in all messages
      • Select RADN and click to expand, click Quick values, and then Add to dashboard when you see the graph.
    • Certs issued per day
      • Search in the last 30 days
      • Select Day in the Histogram and then click Add to dashboard
    • Exceptions last week
      • Search in the last 7 days
      • Exception
      • Select Hour in the Histogram and then click Add to dashboard

    You can now go to your dashboard and rearrange the widgets using Unlock/Edit.

    Tomas Gustavsson

    Friday, October 5, 2018

    Presenting EJBCA 6.15 and one word: ACME

    Version 6 of EJBCA is beginning to near its end, and the team are looking forward with great anticipation to be able to give you all a look at what's coming with EJBCA 7. That said, we're sending off the last feature release of EJBCA 6 with a helluva bang: full support for the ACME REST protocol! 
    Image result for acme

    ACME Protocol Support

    Nearly done by the release of 6.14 but not quite there, EJBCA 6.15's main feature is our support for the ACME protocol, up unto and including all mandatory features in draft 12. Naturally we've implemented it with full support for proxying communications over Peers through our RA, and support for multiple configurations using aliases as we do with other protocols.

    As it's a commonly asked question, we'd like to state here that our implementation has been verified against CertbotPJAC and ACME Tiny, and our documentation describes how to configure them.

    Wildcards for Custom Certificate Extensions

    We've added two minor features to Custom Certificate Extensions: 

    Firstly, we've added wildcards (identified by an '*') to the OID field, which allows a defined extension to match against any array of extensions defined in an incoming request (e.g. in the above example, any request containing an extension ending in .123. The second addition is the Required property, which is by default checked. Unchecking this property makes an extension available to be requested in the enrollment request but not necessary. 

    Roadmap Update

    Development of EJBCA 7.0 is now underway, and while many of you will be pleased at the new Common Criteria certification that's incoming, the initial UI changes won't be monumental at first. This is because most of the work is being done behind the scenes to pay back a monumental technical debt which has been incurred over the years in the UI module, and in order to maintain stability while the UI is being worked on we're making the changes as slow and gradual as possible. 
    From The Oatmeal

    What you'll be seeing next over the coming months will first be a normalization of UI functionality (making sure that similar actions across different pages behave in the same way), followed by a massive renovation of our CSS. After that we'll progressively start introducing more tangible improvements to the UI. 

    Upgrade Information

    Read the EJBCA 6.15 Upgrade Notes for important information about this release. For upgrade instructions and information on upgrade paths, see Upgrading EJBCA.

    Friday, August 24, 2018

    Minor Release: EJBCA 6.14.1

    Hi folks, we'd like to send the summer off with a minor release based the latest version of EJBCA: 6.14.1
    This minor primarily fixes some issues that some users reported when running EJBCA 6.14 on JBoss 7.1.1GA, due to some race conditions and library collisions in that particular version that didn't come up during testing. We also took the chance to fix some other minor issues that came up late during QA that we believe should hold you over for the time being. For a full list of new features and implemented improvements in EJBCA 6.14, see the EJBCA 6.14 Release Notes.
    In other news, we've decided to release our ACME implementation before moving on to EJBCA 7.0, so you can look forward to seeing EJBCA 6.15 in the next few weeks. 
    This minor release does not involve any upgrade steps or notable database changes. Read the EJBCA 6.14 Upgrade Notes for important information about the release. For upgrade instructions and information on upgrade paths, see Upgrading EJBCA.

    Tuesday, August 7, 2018

    Presenting EJBCA 6.14: A Plethora of Protocols

    It's with no small amount of pride that we'd like to announce the release of EJBCA 6.14, one of the most feature rich releases to come out in a long while. Let's get straight to it, because we have quite a bit to discuss. 

    New Features

    EJBCA 6.14 introduces a ton of long awaited functionality primarily centered around protocols, to supplant our already extensive support for SCEP, CMP, EST and our homegrown WS API. 

    The Certificate Management REST API

    A long requested and requested feature is for EJBCA to support a spick and span new REST API, and EJBCA 6.14 introduces the first iteration of our Certificate Management REST Interface

    Screenshot of the offline API documentation
    So far we've only implemented basic certificate management methods, and we'll be slowly moving on with implementing more powerful features in the near future. 

    You'll find the complete offline API as a part of our documentation here, or deployed locally with your EJBCA installation. For those of you wishing to integrate with EJBCA using REST we deploy Swagger on non-production installations in order to expose the API. Just like with all new protocols added to EJBCA, the REST API is disabled by default and needs to be manually activated. 
    Sceenshot from the online Swagger UI

    Complete Proxification of the EJBCA Web Services API 

    A huge milestone for the EJBCA, we put in a huge effort into providing proxification for nearly all EJBCA WS calls. This means that CAs relying on communication with 3rd party applications can now be placed behind an outgoing-only firewall, with communications being relayed through an EJBCA RA. 

    Roadmap Update

    We're now looking forward to Q3 and EJBCA 7.0, which will be our next Common Criteria candidate. In doing so our goal is to make the complete technology leap from JSP to JSF in our CA UI, a first step to greatly improving the usability of EJBCA. Be also aware that EJBCA 7.0 will drop support for JDK7, so if you haven't upgraded to JDK8 or later yet we strongly recommend doing so. EJBCA 7.0 will also hopefully provide full support for the ACME protocol. 

    Mike Agrenius Kushner
    Product Owner, EJBCA

    Monday, June 11, 2018

    From PrimeKey Tech Days 2017: EST Update

    Next up in PrimeKey's series of Tech Days videos is Michael Luken from Cisco who spoke about the EST Protocol, which has been supported by EJBCA ever since version EJBCA 6.11.0. Make sure also to check out this excellent guide to setting up EST written by Tomas a few weeks ago.

    Too see many more lecture like this, come and visit us this fall.