Monday, March 4, 2019

EJBCA 7.0.1 - PSD2 and SN Entropy

Hot on the heels of EJBCA 7.0, we'd like to present the release of EJBCA 7.0.1 - implementing a ton of neat functionality that didn't make the cut for the main release. On top of the list of most commonly requested features is PSD2 support, but please read on to find all the reasons to upgrade to EJBCA 7.0.1!

Full PSD2 Support

EJBCA 7.0.1 provides full support for the Payment Services Directive as defined by EU Directive 2015/2366. PSD2 allows eIDAS Trusted Certificate Providers to issue PSD2 QWAC certificates to third party FinTech companies, which in turn gives them access to financial APIs hosted by European banks. To enable PSD2 in your instance of EJBCA, scroll down to the QC Statements extension of your certificate profile and enable the PSD2 option. 
 This will enable PSD2 fields in the RA UI during enrollment.
If you'd like to read more about PSD2, we've written blog post about it on PrimeKey's blog and right here on our own development blog.  

Domain Blacklist Validator

As a request from some of our CABF-customers, we've implemented a Domain Blacklist Validator. The new Validator takes a list of partial and complete domain names, and can be configured to either block them outright (if run during the data phase) or cause an approval action to be triggered in the final approval step (if approvals are activated). 
All of the approving RA administrators in the final approval step will be shown the following warning before the approval passes:

dnsName SAN can be Automatically Populated by the CN

We've added a setting to End Entity Profiles to allow the dnsName Subject Alternative Name field in a certificate to be filled in by the Common Name (CN) value in the Subject DN.

Configurable SN Entropy, Default Value Raised to 20 Octets

CA/B Forum requires the use of 64 bit entropy when generating serial numbers (see CABF Ballot 164). Due to only positive values being valid serial numbers, 8 octets will only result in 63 bit entropy as the most-significant-bit will always be 0, hence we recommend larger sizes than 8 octets. Previously this was set using the property ca.serialnumberoctetsize in cesecore.properties, which has now been dropped and the value is instead set directly in the CA.
Possible values may range between 4 and 20 octets, and the default for all new CAs is 20 while upgraded CA's will retain whatever value was set in ca.serialnumberoctetsize, or 8 if none was set. 

Downloadable CSRs

In EJBCA 7.0.1 we've started storing CSRs along with the associated certificate (instead of only the last submitted CSR as it was earlier), so you now have access to download and review all CSRs submitted and processed in the past.

URL Metadata Type Added to Approvals

Upon popular request, we've added a URL metadata type to the partitioned approval profiles. It allows the approving RA administrator to enter a URL while performing the approval, e.g pointing to a file upload at an external location.
Upon later review of the approval, it will show up as a hyperlink:

Experimental: Configuration Checker

Lastly, we're trying out an experimental new feature in EJBCA 7.0.1, the Configuration Checker. It displays an (incomplete) list of common configuration issues on the front page. 
If you'd like to try it out, it can be activated in its own tab under the System Configuration:

Roadmap Update

Common Criteria

Our common criteria process is ongoing - the Security Target (ST) is now complete and has been sent for evaluation. Preliminary date for a certified version of EJBCA is still projected to be at the end of this summer. 

Appliance Release

EJBCA 7.0.1 will be available on Appliance 3.3.0, due at the end of March/beginning of April.

Up Next

The teams are rearing to go to work on EJBCA 7.1. Main features are going to be Partitioned CRLs, multi-value RDN support and a couple of surprises. See you then!

Cheers,
Mike Agrenius Kushner
Product Owner, EJBCA

Friday, February 22, 2019

eIDAS and PSD2, what's new for PKI and what can you do?

What does PSD2 have to do with eIDAS?

With the introduction of the Revised Payment Service Directive (PSD2) in EU there are many changes for Payment Service Providers, but there are also some changes for eIDAS (Trust Service Providers (TSPs). Payment service Providers (PSPs) will be required to use Qualified Certificates for electronic seals and website authentication. Specifically for PSPs there are new fields in the QC statement in certificates issued to for this purpose. With PSD2 the QC statement is an interesting mix of issuer specific field (static) and subject specific fields (dynamic). For general eIDAS QC statement information see our earlier blog post.

PSD2 Specific Certificate Fields

The PSD2 specific fields are specified in the recently released ETSI Technical Specification ETSI TS 119 495 in section 4.

Lets look at the new fields and what they mean. There are four required fields in TS 119 495:
  • Authorization number
  • Roles of PSP
  • NCAName
  • NCAId
The authorization number is a registration number of the payment service provider. This number must be included in the Subject DN of the certificate, in the organizationIdentifier DN attribute. This is a dynamic field, different for each certificate issued to different PSPs, but the same for multiple certificates issued to the same PSP. OrganizationIdentifier is supported in EJBCA Enterprise PKI from version 6.5.2. The other three elements are part of the QC statement.

PSD2 Qualified Certificate Statement

The PSD2 specific fields in the qualified certificate statement are specified in ETSI Technical Specification ETSI TS 119 495 in section 5.

Every PSD2 Third Party Payment Service Provider can have one or more of four different roles (described in section 4.2 of TS 119 495). This means this must be a dynamic field to be set by the TSP when issuing the certificate to the PSP. The four roles are account servicing (PSP_AS), payment initiation (PSP_PI), account information (PSP_AI) and issuing of card-based payment instruments (PSP_IC).

The NCAName and NCAId is the name and ID of the National Competent Authority (NCA). This is for example BaFin in Germany. These are specific to the country where the PSP is registered. Since TSPs can issue certificates within any country in EU, this also means that the NCAName and NCAId fields must be dynamic fields to be set by the TSP when issuing the certificate to the PSP.

PSD2 QC Statements is supported out of the box in EJBCA Enterprise PKI from version 7.0.0. In earlier versions they can be created with custom extensions in order to produce test certificates.

Creating PSD2 Certificates with EJBCA

To issue PDS2 certificates with EJBCA Enterprise (7.0.0 and later):
  • Check the ETSI PSD2 QC Statement checkbox in the Certificate Profile
  • Include the PSD2 specific fields when issuing the certificate

./ejbcaClientToolBox.sh EjbcaWsRaCli edituser psd2 foo123 true "CN=PSD2 eSeal Certificate,organizationIdentifier=12345678-9876,O=PrimeKey,C=SE" NULL NULL ManagementCA 1 PEM NEW User Client NULL  NULL NULL "QCETSIPSD2ROLESOFPSP=0.4.0.19495.1.1;PSP_AS" "QCETSIPSD2NCANAME=PrimeKey Solutions AB, Solna Access, Plan A8, Sundbybergsvägen 1, SE-17173 Solna" "QCETSIPSD2NCAID=SE-PK"
You can also set PSD2 specific fields in the web UI (EJBCA 7.0.1 and later), by specifying those to be used in the End Entity Profile:
After that you will be able to enter PSD2 fields in the Admin UI and the RA UI:



PSD2 Certificate Timeline

Payment services must provide account information and payment services with adequate documentation of the technical interface and a corresponding test environment that works with PSD2 certificates from March 14th 2019. From September 14 2019, all service providers must be PSD2-compliant.

EJBCA Enterprise

We strive to support all relevant open PKI standards and it is important to keep EJBCA Enterprise up to date with new and emerging standards. Since EJBCA 6.5.2 eIDAS compliance should be easily achieved on the level of PKI, and the new PSD2 specific QC statement is fully supported in EJBCA 7.0.1.

Cheers,
Tomas Gustavsson
CTO 

 EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey.

EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

Monday, February 18, 2019

The (updated) Definitive EJBCA Upgrade Guide

With the release of EJBCA 7.0 and subsequent drop of support for JDK7/JEE6, we've updated the upgrade guide that we published back in 2017 to reflect these changes. With no further ado, here it goes:

tl;dr:

The official steps for upgrading any EJBCA installation are:

If running EJBCA < 4.0.16 on JDK6 or earlier:
  1. Upgrade to EJBCA 4.0.16
  2. Run ant upgrade from the console
  3. Run ant post-upgrade from the console
  4. Continue below
If running EJBCA >= 4.0.16 but < 5.0.12 on JDK6 or earlier:
  1. Upgrade to EJBCA 6.3.2.6
  2. Run ant upgrade from the console
  3. Run ant post-upgrade from the console
  4. Upgrade to JDK8 
  5. Upgrade application server to a JEE7 supporting application server
  6. Deploy the latest version of EJBCA 
  7. Run ant upgrade from the console
  8. Run post-upgrade from the UI
    If running EJBCA >= 5.0.12 but < 6.4.0:
        1. Upgrade to JDK8 
        2. Upgrade application server to a JEE7 supporting application server 
        3. Upgrade to latest version of EJBCA 
        4. Run ant upgrade from the console
        5. Run post-upgrade from the UI
        If running EJBCA >= 6.4.0:
        1. Upgrade to latest version of EJBCA 
        2. Run post-upgrade from the UI

        Example:

        A typical upgrade path:

        1. EJBCA 4.0.16 (on JDK6, JBoss 5.1.0.GA) 
        2. EJBCA 6.3.2.6 (on JDK6, JBoss 5.1.0.GA) 
        3. EJBCA 6.3.2.6 (on JDK8, WildFly 12) 
        4. EJBCA 7.x

              Concepts

              The background to writing this guide both stems from the understandable confusion in regards to upgrading EJBCA and many of our users experiencing problems when upgrading decade old installations. Thus there are some concepts we'd like to go through and explain:

              The Intermediate Release: EJBCA 6.3.2.6

              During EJBCA 6.8.0 we refactored the roles and access rules massively, which lead to an upgrade break when upgrading from versions of EJBCA prior to 5.0 (though upgrading via EJBCA 5.0 was still possible). As we realized that solving this issue while preserving 100% uptime requirements (see below) was impossible, as well as due to the technology jump (see the next section) and bugs that we discovered while testing upgrading from ancient installations, we created EJBCA 6.3.2.6 in order to handle all the intermediate steps. As of today EJBCA 6.3.2.6 is published and available in the Community Edition on SourceForge, and in the download area for customers.  

              Technology Jump - JDK6 → JDK7

              When: EJBCA 6.4.0

              All good things must come to an end, as must support for legacy runtime versions. As much as we value not having to put our customers through unnecessary hoops by forcing them to upgrade underlying technology such as the JDK, at some point we have to drop support due for several reasons: being held back by not being able to use modern developments, because other dependent systems like Application Servers drop support as well and because the JDKs themselves come to the end of their service lives and will no longer receive support from the vendor. 

              Technology Jump - JEE5 → JEE6

              When: EJBCA 6.4.0

              In EJBCA 6.4.0 we decided to move on to JDK7, which means that it can no longer be deployed to application servers based on JDK6 such as JBoss versions 4 and 5. The latest version that can still run under JDK6 is EJBCA 6.3.2.6. For an upgrade path this means that you can continue running on your old JBoss 5.1.0.GA server (JEE5) up to, and including, the EJBCA 6.3.2.6 intermediate release. At this stage you must upgrade JDK and the application server to JDK8 and JBoss EAP 7 or WildFly 10.

              Technology Jump - JDK7 → JDK8

              When: EJBCA 7.0.0

              With the planned drop of official support from JDK7 from Oracle during 2019, we've decided to drop JDK7 support. Internally this allows us to upgrade now aging libraries which have long since ceased receiving security updates.

              Technology Jump - JEE6 → JEE7

              When: EJBCA 7.0.0

              The loss of JEE6 support means that we've taken the chance to upgrade persistence definition files and library schemas to JEE7 standards. This means that EJBCA will no longer render on JEE6 application servers, meaning that minimal supported AS's are JBoss EAP7/Wildfly 10. 

              100% Uptime during Upgrade

              When: EJBCA 4.0

              While this may be familiar to many of you, EJBCA has ever since version 4.0 supported full uptime during upgrades for clustered installations. What this means is that we pledge that a clustered installation can continue to sign certificates, issue CRLs and answer OCSP queries during the upgrade process with no noticeable downtime for the end user. 

              This is why the upgrade process you may be familiar with is split up into two steps: upgrade and post-upgrade. In short, upgrade performs whatever steps may be required for the first node to be upgraded to be able to function once it comes online again, while post-upgrade performs whatever steps that remain (such as clean up) that can only be performed once all nodes are running the latest code. 

              Automatic Upgrade

              When: EJBCA 6.4.0

              Stunningly, prior to EJBCA 6.4.0 we hadn't actually thought of tracking the database version internally, thus requiring our user to manually enter this value. From EJBCA 6.4.0 and later we do in fact track this, doing away with the need to run the upgrade command entirely. Instead, it'll be automatically run from the first node running the upgraded code. 

              post-upgrade from Console

              When: EJBCA 6.8.0


              In a similar vein, as more and more of our customers run EJBCA on the PrimeKey Appliance and thus don't have access to the command line. As of EJBCA 6.8.0 it's been possible to perform post-upgrades from the UI. When a post-upgrade is required, the System Upgrade option will appear in the menu:
              Choosing it will bring you to a screen used to perform the post-upgrade action:

              Conclusion

              With this blog post and our latest round of QA, we hope that we've solved all existing upgrade issues, and that we can make running the latest version of EJBCA as easy and manageable as possible.

              Cheers!
              Tomas Gustavsson
              CTO

              Mike Agrenius Kushner
              Product Owner EJBCA

              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.

              Cheers!
              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. 

                Cheers!
                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"/>
                    <formatter>
                        <pattern-formatter pattern="%-5p [%c] (%t) %s%E%n"/>
                    </formatter>
                    <properties>
                      <property name="appName" value="WildFly"/>
                      <property name="facility" value="LOCAL_USE_5"/>
                      <property name="serverHostname" value="ec2-52-72-41-146.compute-1.amazonaws.com"/>
                      <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"/>
                    </properties>
                </custom-handler>

                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:

                <root-logger>
                    <level name="INFO"/>
                    <handlers>
                        <handler name="CONSOLE"/>
                        <handler name="FILE"/>
                        <handler name="SYSLOGTCP"/>
                    </handlers>
                </root-logger>

                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
                  • EVENT:CERT_CREATION
                  • Click Add count to dashboard
                • CERT_REVOKED last day
                  • Search in the last 1 day
                  • EVENT:CERT_REVOKED
                  • Click Add count to dashboard
                • Certs issued by SuperAdmin all time
                  • Search in all messages
                  • EVENT:CERT_CREATION AND RADN:CN=SuperAdmin
                  • Click Add count to dashboard
                • Certs per RA
                  • Search in all messages
                  • EVENT:CERT_CREATION
                  • 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
                  • EVENT:CERT_CREATION
                  • 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.



                Cheers,
                Tomas Gustavsson
                CTO 

                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.