Activity Not Available

News

  Analyzed 2 months ago based on code collected 5 months ago.
 
Posted 22 days ago by nore...@blogger.com (tomas)
PKI Appliance takes HA Clustering to the next levelHistorically, setting up and maintaining High Availability (HA) setups for PKI, required a lot of knowledge about the database in use and how it would interact with HA.

Lately, the packaged ... [More] PKI product PrimeKey PKI Appliance (running EJBCA and/or SignServer), manages to hide the HA complexity and makes HA easy to setup, robust during operation and simple to handle during recovery. Clustering a PKI has never been easier!

On the PKI Appliance we define the meaning of High Availability as being able to keep services running non-stop, with full data integrity for all included applications.
High Availability Fail Scenarios Real High Availability requires a cluster setup of three nodes. The reasoning here is that in the case of a node failure, the system should continue to operate on its own, without any administrator measures needed.

Hot standby with manual fail-over is a two nodes cluster setup, which to a lesser extent reduces administration efforts for running systems. Here, the assumption is that depending on which node eventually fails, the system either continues to operate or needs to have a button clicked.

With its handy instructions and simple web GUI configuration, PrimeKey PKI Appliance makes it possible to quickly set up a cluster for Disaster Recovery (includes a main site and a remote site).
Technical detailsHigh Availability with the PKI Appliance is implemented using database replication between cluster nodes connected within a network. Using active-active cluster technology means that all the nodes can be fully utilized in the cluster setup. The implementation uses regular network connectivity over the application interface for all cluster communication, which means that cluster nodes don’t have to be placed physically close, as long as they have good network connectivity.

The drawback of most cluster technologies, is that a node cannot distinguish between a failure of another node (such as a broken power supply) and disrupted network connectivity (such as a broken network switch). So in order to avoid a situation where cluster nodes start to operate independently and get diverging data sets, a so called split brain, the cluster nodes take a vote and cease to operate unless they are part of the majority of connected nodes. This way there is only a single data set that can be updated at a specific time.

In case of a temporary network failure, disconnected nodes automatically synchronize their data as soon as the network is back, then start to operate again as if nothing had happened.
Howto: Setting up a 2 node cluster (Hot standby with fail-over)Using the Appliance Web Configurator it's easy to set up a two node cluster in a few easy steps. Setting up a three node PKI cluster (real High Availability) works the same way, and clustering a PKI has never been easier! 
Make an installation according to the standard installation procedure on the initial Appliance node.On the initial node, go to the cluster tab in the Appliance Web Configurator. To start with it shows the Appliance running as a single instance.
Still on the initial node, add a connection (IP address) to where the second node’s application interface will be. The Appliance will now configure the cluster settings and produce a setup bundle for the second node.

Download the setup bundle for the second node by clicking Create and Download.
Factory reset the second node and connect to the Web Configurator.

On the second node, select the Connect to cluster option and upload the setup bundle.

After the installation has been completed, you should be able to manage the new node using the same login credentials as with the first one.The two nodes are now installed and can be used. Status of the second cluster node shows up as Connected.
More information
Basic information on EJBCA Enterprise PKI and PKI Appliance is available here.
EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries. [Less]
Posted 3 months ago by nore...@blogger.com (Mike)
We hope that you'll get as excited as we are about our latest new EJBCA feature: Peer Systems. We'd like to take this blog post to tell you all a little about what this means and how EJBCA Peer Systems will improve your PKI, as well as give a simple ... [More] tutorial on how it works.

Peer Systems is a protocol for communicating between EJBCA nodes securely. Its purpose is to allow propagation of data and information in a synchronous fashion, without requiring a safe connection or an isolated network. In previous iterations of EJBCA the only means of communication were either the WebService API or direct database publishing. Web services is on one hand too slow to use for data heavy applications like very high speed certificate publishing, while database publishing needs database specific security measures or a closed network, seldom an option for OCSP.

Two requirements have prompted Primekey to move towards developing a brand new feature set:
The need from the PKI Appliance platform to be able to set up OCSP responders without redeploying the application, requiring steps to be performed via the CLI or set up special database rules.The value of enabling our users to spend less time digging into the server configuration, setting up database connections. VA machines can often be physically or geographically inaccessible from their respective CAs, and Peer Systems is a step in the right direction making things easier to set up using only the GUI.Note that this feature is for EJBCA Enterprise customers only. If you'd like to find out how to enroll, please contact us.
Initial ConceptsThis tutorial will cover an installation involving two machines in a PKI setup, a Certificate Authority (CA) and a Validation Authority (VA) serving as an OCSP responder for the CA. We will be building on concepts introduced in earlier versions of EJBCA 6, so if you're not familiar with the creation of End Entities or OCSP Key Bindings, feel free to check our User Guide.
Establishing TrustFor this tutorial, all communication will be initiated on the CA, so our connection will be one way. The first thing we need to do is to establish trust between the two machines (CA and VA), and we will do so by creating an Authentication Keybinding on the CA.
Click on the Internal Key Bindings item in the menu and choose the AuthenticationKeyBinding tab.Create an authentication keybinding using the crypto token of your choice. The crypto token chosen will be the one providing keys for the TLS connection.Return to the AuthenticationKeyBinding overview page. Notice that your newly created keybinding isn't enabled, and doesn't have a certificate. Let's fix that.Click on the CSR button in the Action column. On the CA machine create an End Entity and issue the keybinding certificate. Make sure that Key Usage: Digital Signature and Key Encipherment and Extended Key Usage: Client Authentication are set in the Certificate Profile.Return to the AuthenticationKeyBinding overview page on the CA machine. Import the certificate you got in the previous step to your authentication keybinding by clicking the Update button.Enable your keybinding.A properly set up Authentication Keybinding
Setting up the Outgoing Peer on the CANow we'll talk about how to set up our CA and VA as Peers.
Incoming connections are disabled by default, so first of all on the VA, click on Peer Systems in the admin menu and then click on the Allow incoming connections checkbox.Now go to the CA, and enter the Peer Systems page here as well.Click on the Add button under Outgoing Peer Connectors.Create new Peer, making sure to enter the VA's address (matching the VA's server side TLS certificate) and the selected authentication keybinding.A newly created Outgoing Peer on the CA
Setting up the Incoming Peer on the VAClick the Ping button for the Outgoing Peer (on the CA) and you'll get the reply "Unable to connect to peer. Unauthorized." Not to worry, you simply have to add rights on the VA.Import the CA certificate of the CA (used to issue the certificate for the End Entity on the CA in the steps above) as an External CA.Go to the VA, and under the Incoming Connections section you should see the incoming connection from the CA. To the right you'll see the button Create Authorization (see screen shot for required options).Either add the incoming peer to an existing role or go right ahead and create a new one.In the next screen, choose the required rights for the incoming connection and click on Create Authorization.Returning to the Peer Systems screen, there should be a newly created role under the First matching role column of your created peer.Returning to the CA, you should be able to ping the VA as before, now receiving a response.Congratulations, you've established trust.Authorizing an Incoming Peer
Setting up a Validation Authority Peer PublisherThe last step is to set up a Validation Authority Peer Publisher, which happily works just like the old VA Publisher.On the CA, go to Publishers and create a new publisher.Choose Validation Authority Peer Publisher as a type and choose the newly created peer as a Peer System.Click Save and Test Connection and you're done!You've now set up VA Publishing between CA and VA, without having to grant any database rights or allowing direct database access over network to your VA. Cheers!

More information
Basic information on EJBCA Enterprise PKI is available here.
EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries. [Less]
Posted 4 months ago by nore...@blogger.com (markus)
SignServer 3.6 brings great improvements in both crypto token configuration and management. There is now the advantage of single crypto token configuration and, related to this, re-keying has become far more convenient.

Single crypto token ... [More] configurationAs crypto token configuration in SignServer 3.6 is now done in a single spot, management has become significantly simpler.

In previous versions, the necessity to configure keystores (soft or PKCS#11) in each worker resulted in duplicated configuration. The repetitive steps couldn't be avoided even when all workers shared the same keystore or HSM slot.

From version 3.6 there is separation between worker and crypto token configuration, which eliminates duplicate configuration entirely. You simply set up a single crypto worker (a special type of worker). Other workers, using key-pairs in the same keystore or HSM slot, will then point to the singly configured crypto worker.

One crypto token and multiple workers
Crypto token referenced from another worker
Rekeying without production stopAchieving rekeying without production stop used to be a bit of a hassle. Special care had to be taken to ensure that at least one signer was available to handle emerging requests.

To everyone's satisfaction rekeying has improved as of version 3.6. Crypto workers now stay active as the keying process does not change the configuration of the crypto token. Entirely superfluous, special measures to avoid production halt are now history.

In practice, the process of rekeying (generating a new key-pair and getting a new certificate for it)  always has to be done before the signer's certificate expires. In the Admin GUI every operation is accessed in the tool bar, from the corresponding buttons (screen shot below) which basically follow these five steps:
Activate the workerRenew the key-pairTest the key-pairGenerate CSRInstall certificates
AdminGUI toolbar

Step 2 previously put the worker in an off-line state but with the new crypto worker configuration this is not the case, and it can thus stay active at all times, greatly facilitating re-keying in production.
Trying it outLet's configure a PDF signer which uses keys provided by a crypto worker.

Set up a new crypto worker configuration by copying the sample config file: $ cp doc/sample-configs/keystore-crypto-configuration.properties \
my-crypto-config.properties
Edit my-crypto-config.properties by changing the keystore path to point to the sample keystore provided:GLOB.WORKERGENID1.CLASSPATH=\
org.signserver.server.signers.CryptoWorker
GLOB.WORKERGENID1.SIGNERTOKEN.CLASSPATH=\
org.signserver.server.cryptotokens.KeystoreCryptoToken
WORKERGENID1.NAME=CryptoTokenP12
WORKERGENID1.KEYSTORETYPE=PKCS12
WORKERGENID1.KEYSTOREPATH=\
/opt/signserver/res/test/dss10/dss10_signer1.p12
Apply the configuration (replace WORKERID with ID printed):$ bin/signserver setproperties my-crypto-config.properties$ bin/signserver reload WORKERID
Activate the crypto token in the crypto worker (password is "foo123"):$ bin/signserver activatecryptotoken CryptoTokenP12
Set up a new PDF signer using your newly activated crypto worker:$ cp doc/sample-configs/qs_pdfsigner_configuration.properties\
my-pdf-config.properties
Set my-pdf-config.properties to point to the crypto worker:GLOB.WORKERGENID1.CLASSPATH=\
org.signserver.module.pdfsigner.PDFSigner
WORKERGENID1.NAME=PDFSigner
WORKERGENID1.AUTHTYPE=NOAUTH
WORKERGENID1.CRYPTOTOKEN=CryptoTokenP12

Apply the configuration (replace WORKERID with ID printed):$ bin/signserver setproperties my-pdf-config.properties$ bin/signserver reload WORKERID
View the status of the workers:$ bin/signserver getstatus brief allCurrent version of server is : SignServer CE 3.6.2

Status of CryptoWorker with id 1 (CryptoTokenP12) is:
   Worker status : Active
   Token status  : Active

Status of Signer with id 2 (PDFSigner) is:
   Worker status : Active
   Token status  : Active
   Signings      : 0

You can also get more information by writing "complete" instead of "brief" or by using the Admin GUI:$ bin/signserver-gui
More informationBasic information on SignServer Enterprise is available here. For entire documentation, see signserver.org. [Less]
Posted 7 months ago by nore...@blogger.com (tomas)
EAC 2.10 CV certificates are supported as of EJBCA Enterprise 6.1.0. This is an upgrade from the previously supported EAC 1.11. So, what's new in EAC 2.10 and why would you even need EAC certificates at all?

About Extended Access ... [More] ControlExtended Access Control (EAC) is the technology used to protect fingerprints (or irises) in EU member states' e-passports, but in some eIDs other information is protected as well. As used in the EU, EAC is defined in the BSI technical specification TR-03110. Based on public key infrastructure (PKI), EAC works as an authentication mechanism between the terminal and the ePassport/eID chip. The specification includes several steps such as both chip- and terminal authentication, but only terminal authentication concerns PKI.

In an EAC process, each inspection system or terminal is given a CV Certificate (CVC) which gives the inspection system privileges to perform specific actions, or to read certain data from the e-passport or eID chip. If the inspection system cannot authenticate itself towards an e-passport or eID chip, the latter will deny access to the data or function.

The news in EAC 2.10So what are the differences in EAC 2.10 compared to EAC 1.11? As mentioned, 1.11 was designed for ePassports only. With EAC 2.10 the use cases have been extended to other security documents, such as eIDs. In the context of EJBCA, we are primarily interested in terminal authentication (the part where the PKI implements something). Here, the main difference in EAC 2.10 is additional access control templates, used to specify new types of terminals relating to eIDs and digital signatures. There is also room for extensions, but since none have been specified at this stage and no sample certificates are using extensions, this is mostly a placeholder for future additions.

The CVC Terminal Type options illustrated
The news in EAC 2.10 may most easily be illustrated by a few screenshots of the Admin GUI in EJBCA Enterprise 6.2.0.
In EAC 1.11 the only CVC terminal type available  was Inspection System (allowing you to select DG3 and/or DG4). This option still provides an inspection system able to read fingerprints, and/or iris data, from e-passports. In the first image however, you can see the EAC 2.10 CVC terminal type (upper left corner) with two new options next to Inspection System: Authentication Terminal and Signature Terminal. Click the image to enlarge!

CVC terminal type
So, what hides behind the new Authentication Terminal and the Signature Terminal options?
The Authentication Terminal can be given fine grained (read and write) control to any data group on an eID, as well as control to additional eID functions such as PIN Management and Age Verification.
Authentication Terminal (pic 1)
Authentication Terminal (pic 2)
The Signature Terminal on the other hand, can either be given the role of an Accreditation Body or a Certification Service Provider, where each can be allowed to generate signatures and/or qualified signatures.

Signature Terminal (pic 1)
Signature Terminal (pic 2)
Summary
To sum up the additional features in EAC 2.10:
New terminal types for using eIDs.New access controls for mentioned terminals.Possibility for extensions.
More informationBasic information on EJBCA Enterprise PKI is available here.
EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

About the author
Tomas Gustavsson, CEO/CTO of PrimeKey, founder of EJBCA
Contact me at tomas(at)primekey.se.
Follow me on Twitter.
Follow PrimeKey on Twitter. [Less]
Posted 11 months ago by nore...@blogger.com (tomas)
As of the release of version 6.0.4, EJBCA Enterprise now supports Certificate Transparency RFC6962.
Google initiative to increase https securityCertificate Transparency (CT) is an initiative by Google to increase security and auditability of the ... [More] https ecosystem itself. These important aims are accomplished by having CAs (CA services using a software such as EJBCA) issue TLS certificates, which are transparently auditable and exactly reveals which certificates have been issued. The purpose of CT is to create public audit logs of all certificates issued by the public SSL/TLS CAs. For example, this means the owners of a certain web domain can monitor CT Log servers, to see if there are any unknown or suspicious TLS certificates issued for their domain. In addition, the presence of audit records is planned to be required for EV certificates in Google Chrome from February 2015. And perhaps later on for other web browsers and non-EV certificates as well.

Note that Certificate Transparency is only relevant for CAs issuing public SSL/TLS certificates; other types of CAs mustn't use CT at this time. More information can be found on the CT website.
The specification of Certificate Transparency is still being discussed, and a follow up to RFC6962 will likely be available in the not so distant future, including (among other things) a way to handle private subdomains.
How EJBCA Enterprise perceives Certificate TransparencyFrom the CA's angle, CT works by publishing pre-certificates from itself to the log servers; then in immediate response, Signed Certificate Timestamps (SCTs) are retrieved. Certificate and timestamp exchange is done within a single operation, so requesting an SCT for a certificate also publishes it. The resulting SCTs can then be sent to end-users in any of three different ways: 1) in a certificate extension (embedded when issuing the real certificate), 2) in a stapled OCSP response extension, 3) and/or in a TLS extension (yes, EJBCA does support all of those methods, including any combination of the three).

The EJBCA Admin Guide describes how to configure EJBCA Enterprise for one or more of the above methods.
For more information, contact:Tomas Gustavsson, CTO of PrimeKey, founder of EJBCA
tomas(at)primekey.se.
Follow me on Twitter [Less]
Posted about 1 year ago by nore...@blogger.com (tomas)
Point of Sale (POS) terminals, communicate not only to all of the cash registers of a store, but also to central location. In order to secure this particular type of communication, and secure other items on the terminals as well, you need to add keys ... [More] and certificates managed by a PKI.
To enable POS terminals to enroll for certificates specifically against an EJBCA® Enterprise PKI server, C2 Company and PrimeKey have successfully installed and used the EJBCA Enterprise clientToolBox on several Toshiba 4690 POS terminals.
About POS and Toshiba 4690Commonly used in POS terminals, the Toshiba 4690 is an operating system which is basically IBM Java and DOS based, using specific 4690 DOS commands. So, if you are used to common computing with Linux or Windows, the Toshiba will appear a bit alien. However, taking the trouble to introduce PKI to the POS system, will enable any user of the 4690 terminals to trade on both strong authentication and encryption.
Steps to Enroll and Renew CertificatesHaving IBM Java on board, helped us run EJBCA clientToolBox on Toshiba 4690, and made it possible to enroll and manage certificates. The Toshiba required some figuring out of which new commands to run, but once that was (elegantly) performed by C2, EJBCA clientToolBox was running ever so nicely.
The following steps are only a single example of how you can use the certificate management capability on POS terminals. In fact, there are limitless possibilities.
Use the Native DOS commands to generate keys and CSRs. Once those are generated you can enroll for a certificate against EJBCA, using clientToolBox.
To enroll new terminals for the first time when they are installed in a store, you can use a pre-installed certificate on the POS terminal image. To enroll for the real terminal certificate you use the pre-istalled certificate temporarily, to enable access from the POS terminal to EJBCA. The pre-installed certificate does not need any admin access in the EJBCA system. Do the following:
Install a new POS terminal with an image, including a pre-installed communication certificate on the image.Register the POS terminal (with serial number or similar) in EJBCA, and you'll receive a one-time enrollment code.Generate keys and a CSR (to the csr.pem file) on the POS terminal, by using DOS commands.Submit the CSR to EJBCA, to get the signed certificate back, using this command:./ejbcaClientToolBox.sh EjbcaWsRaCli pkcs10req terminalSerial enrollmentCode csr.pem PEM NONE certificate.pem
Now you are ready to remove the pre-installed communication certificate from the image, to finally make the image secure, only by its rightful individual certificate. However, to block the POS terminal from accessing store systems (in case the terminal gets stolen or hacked) the latter step can be revoked.
A single PKI administrator action is found in the above work-flow; registering the POS terminal in EJBCA. This is done in order to authenticate the initial enrollment and make sure that no unauthorized terminal receives real certificates, that is, illegitimate access to store systems. With the final certificate installed, the terminal can automatically renew it before expiry, requiring no PKI administrator action during daily operations.
More informationFore more information, or to get in touch with C2 for help with securing your POS terminals, contact Chris or me. Cheers!Chris Chu
chris at c2company.comTomas Gustavsson
tomas at primekey.se
Twitter [Less]
Posted about 1 year ago by nore...@blogger.com (tomas)
The PrimeKey EJBCA® team is happy to announce the release of EJBCA Enterprise 6.1.0.This release resolves several issues, with a few highlights: Increased performance through OCSP improvements; Key Recovery improvements; support for EAC 2.10 ... [More] (ePassport) access control templates.Running on the latest technology platforms, EJBCA Enterprise v.6 is so flexible it is suitable for any organization, cloud, social or mobile system. Faster, more resource efficient, more secure and more user friendly than ever.EJBCA Enterprise *6.1.0* release notesA maintenance release containing 32 new features and improvements, below a selection of the most noteworthy:New featuresNew OCSP features related to RFC 6960, minimizing size of OCSP responses.Implemented OCSP signing algorithm selection from client requested algorithms.CVC certificate profiles (ePassport PKI) now supports EAC 2.10 access control templates.ImprovementsOCSP improvements with more cache control settings.Improvements to Key Recovery, enabling encryption key rollover and providing more information about encryption keys.Ability to build and install EJBCA on Windows platforms.The ManagementCA created during default install, now uses SHA256WithRSA.EJBCA compiles cleanly with Java 8, WildFly 8 and Glassfish 4 (running on those platforms however, is not yet supported).EJBCA can now use certificate serial number longer than 64 bits.Many reported minor issues have been fixed, as well as minor GUI improvements.More informationBasic information on EJBCA Enterprise PKI is available here.For entire technical details view the changelog in the PrimeKey Issue Tracker.
EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries. [Less]
Posted about 1 year ago by nore...@blogger.com (tomas)
IntroductionA convenient method to enroll for certificates and do automatic certificate renewal, is to use the BouncyCastle API to implement a client that uses the CMP (RFC4210) protocol. In this example the implementation is done using java ... [More] code and you need a CA that supports the CMP protocol on the server side.
Using the CMP protocol is a good way to integrate clients and RAs in a PKI, and BouncyCastle API is a great tool for this task. By the way, BouncyCastle needs your support to fund a FIPS certification. Help spread the word. A short background on CMPThe open source CA EJBCA, implements many standard PKI protocols, CMP being one of them.

In the early days of CMP there were mainly commercial SDK implementations, and only a single open source instance (written in C). As always, that slowed down adoption. Nowadays, there is full support for CMP in the governing de-factor standard java crypto API BouncyCastle. No more excuses not to use CMP! :-)

Described more in detail in a previous blog post is CMP and its implementation in EJBCA.
Examples on how to use BouncyCastle CMP APIHere, I will show two different enrollment types (with source code) for the client implementation: 1) an RA using a shared secret authentication and 2) a client using certificate authentication.
These are by no means everything you can do. The RA can also use certificate authentication, or you can do nested messages with multiple layers of authentication. And many, many more! Only your imagination sets the limits :-).

All mentioned configurations can be active at the same time when using EJBCA 6. For complete documentation, see the Admin Guide at EJBCA.org.

Enrollment type 1) RA with shared secret authenticationUsing an RA means the RA is configured to order certificates for its clients. The clients themselves will not be pre-registered by the CA, but will be added by the RA when it enrolls for the client.
To create a CMP enrollment message for an RA, using BouncyCastle:

CertificateRequestMessageBuilder msgbuilder = new CertificateRequestMessageBuilder(BigInteger.valueOf(certReqId));
X509NameEntryConverter dnconverter = new X509DefaultEntryConverter();
X500Name issuerDN = X500Name.getInstance(new X509Name("CN=AdminCA1").toASN1Object());
X500Name subjectDN = X500Name.getInstance(new X509Name("CN=user", dnconverter).toASN1Object());
msgbuilder.setIssuer(issuerDN);
msgbuilder.setSubject(subjectDN);
final byte[] bytes = keyPair.getPublic().getEncoded();
final ByteArrayInputStream bIn = new ByteArrayInputStream(bytes);
final ASN1InputStream dIn = new ASN1InputStream(bIn);
final SubjectPublicKeyInfo keyInfo = new SubjectPublicKeyInfo((ASN1Sequence)dIn.readObject());
msgbuilder.setPublicKey(keyInfo);
GeneralName sender = new GeneralName(subjectDN);
msgbuilder.setAuthInfoSender(sender);
// RAVerified POP
msgbuilder.setProofOfPossessionRaVerified();
CertificateRequestMessage msg = msgbuilder.build();
GeneralName recipient = new GeneralName(issuerDN);
ProtectedPKIMessageBuilder pbuilder = new ProtectedPKIMessageBuilder(sender, recipient);
pbuilder.setMessageTime(new Date());
// senderNonce
pbuilder.setSenderNonce(senderNonce);
// TransactionId
pbuilder.setTransactionID(transactionId);
// Key Id used (required) by the recipient to do a lot of stuff
pbuilder.setSenderKID("KeyId".getBytes());
org.bouncycastle.asn1.crmf.CertReqMessages msgs = new org.bouncycastle.asn1.crmf.CertReqMessages(msg.toASN1Structure());
org.bouncycastle.asn1.cmp.PKIBody pkibody = new org.bouncycastle.asn1.cmp.PKIBody(org.bouncycastle.asn1.cmp.PKIBody.TYPE_INIT_REQ, msgs);
pbuilder.setBody(pkibody);
JcePKMACValuesCalculator jcePkmacCalc = new JcePKMACValuesCalculator();
final AlgorithmIdentifier digAlg = new AlgorithmIdentifier("1.3.14.3.2.26"); // SHA1
final AlgorithmIdentifier macAlg = new AlgorithmIdentifier("1.2.840.113549.2.7"); // HMAC/SHA1
jcePkmacCalc.setup(digAlg, macAlg);
PKMACBuilder macbuilder = new PKMACBuilder(jcePkmacCalc);
MacCalculator macCalculator = macbuilder.build("password".toCharArray());
ProtectedPKIMessage message = pbuilder.build(macCalculator);

The above requires a CMP alias with approximately the following EJBCA configuration:
RA mode.HMAC authentication module.Specified secret 'password1'.DN parts with CN as RA name generation scheme.Enrollment type 2) Pre-registered client with certificate authenticationUsing a client means that the client is already registered and present on the CA, able to authenticate itself with a certificate. The certificate can be generated by other means than the CA, or be imported into EJBCA.
To generate a signature protected CMP enrollment message using BouncyCastle:
CertificateRequestMessageBuilder msgbuilder = new CertificateRequestMessageBuilder(BigInteger.valueOf(certReqId));
X509NameEntryConverter dnconverter = new X509DefaultEntryConverter();
X500Name issuerDN = X500Name.getInstance(new X509Name("CN=AdminCA1").toASN1Object());
X500Name subjectDN = X500Name.getInstance(new X509Name("CN=user", dnconverter).toASN1Object());
msgbuilder.setIssuer(issuerDN);
msgbuilder.setSubject(subjectDN);
final byte[] bytes = keyPair.getPublic().getEncoded();
final ByteArrayInputStream bIn = new ByteArrayInputStream(bytes);
final ASN1InputStream dIn = new ASN1InputStream(bIn);
final SubjectPublicKeyInfo keyInfo = new SubjectPublicKeyInfo((ASN1Sequence)dIn.readObject());
msgbuilder.setPublicKey(keyInfo);
GeneralName sender = new GeneralName(subjectDN);
msgbuilder.setAuthInfoSender(sender);
Control control = new RegTokenControl("foo123");
msgbuilder.addControl(control);
Provider prov = Security.getProvider("BC");
ContentSigner popsigner = new JcaContentSignerBuilder("SHA1withRSA").setProvider(prov).build(keyPair.getPrivate());
msgbuilder.setProofOfPossessionSigningKeySigner(popsigner);
CertificateRequestMessage msg = msgbuilder.build();
GeneralName recipient = new GeneralName(issuerDN);
ProtectedPKIMessageBuilder pbuilder = new ProtectedPKIMessageBuilder(sender, recipient);
pbuilder.setMessageTime(new Date());
// senderNonce
pbuilder.setSenderNonce(senderNonce);
// TransactionId
pbuilder.setTransactionID(transactionId);
org.bouncycastle.asn1.crmf.CertReqMessages msgs = new org.bouncycastle.asn1.crmf.CertReqMessages(msg.toASN1Structure());
org.bouncycastle.asn1.cmp.PKIBody pkibody = new org.bouncycastle.asn1.cmp.PKIBody(org.bouncycastle.asn1.cmp.PKIBody.TYPE_INIT_REQ, msgs);
pbuilder.setBody(pkibody);
ContentSigner msgsigner = new JcaContentSignerBuilder("SHA1withRSA").setProvider(prov).build(keyPair.getPrivate());
ProtectedPKIMessage message = pbuilder.build(msgsigner);

The above requires a CMP alias with approximately the following EJBCA configuration (use a new CMP alias so you can run this and the previous config in parallell):
Client mode.EndEntityCertificate authentication module.CN as extract username component.About the authorTomas Gustavsson, CTO of PrimeKey, founder of EJBCA
Contact me at tomas(at)primekey.se.
Follow me on Twitter. [Less]
Posted over 1 year ago by nore...@blogger.com (tomas)
IntroductionImplementing CMP to enroll for certificates and do automatic certificate renewal against a CA that supports the CMP protocol, the open source tool CMP for OpenSSL should be considered. Using the CMP protocol is a great way to integrate ... [More] client and RAs in a PKI, and CMP for OpenSSL is a very promising tool.
Some background on CMPThe open source CA EJBCA implements many standard PKI protocols. One of them is CMP, which has been around since September 2005 when the RFC4210 first was published. In the early days adoption of CMP was progressing slowly due to the great complexity. The huge amount of options still make CMP somewhat cumbersome both to implement and use.

In the beginning CMP was mostly used from RAs, such as card/token management systems and in-house RAs. In the last couple of years adoption of CMP has increased and is now used in several systems, for example in LTE mobile networks where CMP is profiled by 3GPP (supported in PrimeKey's EJBCA Enterprise).

However, being a complex protocol with many options, CMP can be used for many different use cases. From clients that enrolls for certificates with optional automatic renewal, to RAs that registers end entities and issues certificates for those. All combined with several different ways of authentication, such as shared secrets and client certificates. One important distinction to make, is that messages specified by the protocol are one thing, another is the expected behavior in the back end (for example if a client needs to be pre-registered or not, or if any fields are accepted from an RA, or if there are any profile limitations). The messages themselves are specified in the CMP standard, but the behavior is defined by the specific use cases and sometimes standardization groups such as 3GPP.

CMP has been implemented within EJBCA since ECA-99 in 2006. PrimeKey's implementation has matured a lot during this time, and the latest evolution is CMP Aliases. In the current state CMP can be used for an uncountable number of different use cases with different back-end behavior, depending on the configuration.
CMP for OpenSSLThe main obstacle slowing the adoption of any protocol, is lack of free and open source implementations. So it is both pleasing and welcome to see CMP for OpenSSL appear. Being an excellent tool, we hope to see it integrated into OpenSSL at some point.

Note: Before using CMP for OpenSSL you must download and build it. It is not included in any standard distribution of OpenSSL.
Using CMP for OpenSSL as CMP clientHere I will show three different enrollment types; A client with a pre-registered shared secret, a client using certificate authentication, and an RA using shared secret authentication.
There is of course much else you can do. The RA can for example use certificate authentication, you can do nested messages with multiple layers of authentication etc. Only your imagination sets the limits on how to use CMP :-). Along with EJBCA 6 all these different configurations can be active at the same time.

For complete documentation, see the Admin Guide at EJBCA.org.
Pre-registered client with password authenticationDownload the CA certificate to the clientAdd a new end entity in EJBCARun the command./openssl cmp -cmd ir -server ejbca-test.primekey.se:8080 -path ejbca/publicweb/cmp -srvcert MyCA.cacert.pem -user username -pass password -certout clcert1.pem -newkey key1.pem -keyfmt PEM -certfmt PEM -subject "/CN=username/O=My Organization/C=SE"
Where username is the username you added (you have to type it twice it's in the CN as well) and password is the password you entered when adding the end entity.

The above requires a CMP alias in EJBCA with the following configuration:
Client modeHMAC authentication moduleCN as extract username componentPre-registered client with certificate authenticationSince this requires an existing certificate for the client, you can use the above enrollment method to generate it, but other possibilities exist of course.
./openssl cmp -cmd ir -server ejbca-test.primekey.se:8080 -path ejbca/publicweb/cmp/alias1 -srvcert MyCA.cacert.pem -cert clcert1.pem -key key1.pem -certout clcert2.pem -newkey key1.pem -keyfmt PEM -certfmt PEM

Where clcert1.pem and key1.pem is the cert and key generated previously (used for authentication to the same user). clcert2.pem will be the new certificate, and for simplicity we re-use key1.pem as -newkey, but you can generate a new one as well.

The above requires a CMP alias in EJBCA with the following configuration:
Client modeEndEntityCertificate authentication moduleCN as extract username componentRA with shared secret authenticationUsing an RA means that the RA should be able to order certificates for clients of the RA. The clients themselves will not be pre-registered by the CA, but will be added by the RA when the RA enrolls for the client.
./openssl cmp -cmd ir -server ejbca-test.primekey.se:8080 -path ejbca/publicweb/cmp/alias2 -srvcert MyCA.cacert.pem -user user4711 -pass password -certout clcert1.pem -newkey key1.pem -keyfmt PEM -certfmt PEM -subject "/CN=user4711/O=My Organization/C=SE"
Where User and CN should be the same, and afterwards the client will be available as "username" in EJBCA.

The above requires a CMP alias in EJBCA with the following configuration:
RA modeHMAC authentication moduleSpecified secret 'password1'DN parts with CN as RA name generation schemeAbout the authorTomas Gustavsson, CTO of PrimeKey, founder of EJBCAContact me at: tomas(at)primekey.seFollow me on Twitter: primetomas [Less]
Posted over 1 year ago by nore...@blogger.com (markus)
IntroductionSignServer participated in the ETSI CAdES Plugtest Interop event with SignServer developers Markus Kilås and Marcus Lundblad. Here is a summary of Markus's report from the event.
The Plugtest EventThe ETSI Centre for Testing and ... [More] Interoperability (CTI) organized a Remote Plugtest Interop event for CAdES Signatures scheduled from 2nd to 13th December 2013, and later extended to the 20th December.

The event was conducted remotely using the Electronic Signature Plugtest Portal, e-mail and three conference calls.

About 60 companies joined the event.
The Plugtest PortalThe event was conducted mostly through the portal where the participants could download an “inital package”, a zip file with test case specifications for which signatures to create, as well as folders for the different participants.

After creating the signatures (according to the specifications) those could be placed in the participant's folder, the relevant parts of the folder structure zipped together, then uploaded to the portal. The Portal took care of merging the uploaded files and created a new package for download by all participants. In the same way signature verification reports could be uploaded and a matrix with the results could be viewed in the portal.

There were 84 different test cases in the cross-verification part of the event.
SignServer implementationSignServer did not support any form of CAdES prior to the event. We decided to base our implementation on the library SD DSS.
Because of limited time and SD DSS using an older version of BouncyCastle, we simply developed a standalone proof of concept not yet integrated in SignServer. We based our implementation on SD DSS version 2.0.2, but during the event version 3.0.2 was released. Yet, we decided to continue on 2.0.2 through the event, as we already had done a lot of changes, both bug fixes and added features, since it otherwise would have taken too long to merge it to the new version. We also took contact with the authors of the library and got informed about version SD DSS version 4, planned for January-February 2014, with major changes in the verification parts.
Our implementation consisted of a standalone Java CLI application, which could either sign or verify a document. The application used a configuration file (similar to the signer configuration file in SignServer) configuring the CryptoTokens to use.
Test CasesTo easily create all necessary signatures and also perform validation of the other participants's signatures, we used JUnit test cases that could be run from within the IDE. A Java base class contained a single test method for each type of signature to create/verify. The method took care of calling the PoC application with the right properties for each type of signature, and then performed the necessary verifications to check that the signature complied with the test specification. This was implemented using JUnit asserts, and some magic in a base class took care of producing a verification report, according to the plug test specification.
To be able to perform all the tests implemented for all participants, the base class was extended and parameterized with a list of all participants, so that each test method was executed for each participant.
A complete run produced about 600 verification reports.

Results summaryThe support for CAdES-BES, CAdES-BpB and CAdES-T was quite good, except for the missing support for counter signatures (BES-6).For CAdES-EPES some participants were reporting problems.For CAdES-C and CadES-X* we had some issues related to the ordering of revocation information references.We did not perform any CAdES-A and signature upgrades (CAdES-UpdArb).Support for correctly verifying signatures was mostly lacking and we did not put any big effort into resolving that during the event, as the verification support will be largely changed in the next version of SD DSS.ConclusionsWe participated in the event and had good interoperability results for the basic forms of CAdES, during the limited time-frame.
We now have a lot more knowledge about CAdES and the SD DSS library. We also developed a set of test cases that will be helpful when developing and integrating CAdES support in SignServer.
More work is needed to make our CAdES implementation stable and to integrate it in SignServer, as well as adding support for the more evolved forms of CAdES (which we did not have time for during this event).
We look forward to attending the next CAdES PlugTest Event! [Less]