Hello Andreas,

Am 19.10.2016 um 18:51 schrieb [email protected]:
What I try to do is to switch from OpenCA to OpenXPKI.
I am very astonished that this piece of software is still running in the wild ;)

The reason is that it looks like that OpenCA is also not in developing anymore. 
(and OpenXPKI looks easier to configure). There is also an migration from SHA1 
to SHA2 in progress so I thought switching to a better CA is a good idea.
OpenCA went mostly dead when the majority of developers moved away and founded OpenXPKI back in 2005, and so yes - it is a good idea to move over, too.

OpenXPKI looks great so far and I also impressed how it works. Installing it 
via Debian packages was much easier than the old CA via source code :)
We tried hard to do it better.

I think that we just start over with our existing ROOT CA but with new Sub CA's 
when going to SHA2. I was asked if it is possible to migrate all the old 
certificates we have on the OpenCA into the OpenXPKI. So moving 3 OpenCA's into 
one OpenXPKI with 3 realms was my idea. Each realm should then have the old 
certificates and issue new certificates.
So if importing the ROOT and Sub CA certificates is not a problem than I will 
do it. If I'm right only the certificate that is marked as signing token will 
be used.

This is correct, but mind that you also wont be able to create CRLs if you dont add the key and link the signing tokens. It wouldnt be a problem to add the old CAs too, the signer for new requests is always chosen based on the latest notbefore date. So having the "legacy root" fully operational to create CRLs while signing with the new SHA2 CA is no problem. Actually we do so at one of our larger customers now for the third generation of CAs.

After importing the certs you need to tweak one thing: set the "req_key" column in the database to "-1", otherwise they wont show up in the search as they are not considered as end entity certificates.

By the way ... OpenCA is also using the index.txt from OpenSSL. How is OpenXPKI 
doing it?
Thats easy - for each ca action, the index.txt and other files for openssl are created on the fly in a temporary location.

Many Thanks
you are welcome

best regards

Oliver



Mit freundlichen Grüßen / Best regards

Andreas Krieger


-----Ursprüngliche Nachricht-----
Von: Oliver Welter [mailto:[email protected]]
Gesendet: Mittwoch, 19. Oktober 2016 15:16
An: [email protected]
Betreff: Re: [OpenXPKI-users] issuer identifier

Hello Andreas,

Am 19.10.2016 um 14:04 schrieb [email protected]:

I try to import a certificate "openxpkiadm  certificate import --realm
'realmname' --force-no-chain --file 'filename'".

When I do this I get the following error:

ERROR:  null value in column "issuer_identifier" violates not-null
constraint

Well, thats a bug ;)

Would it help to add the option --issuer? But what exactly is the
identifier? If I get the information from a certificate (openssl x509
..) then I don't find anything about the issuer identifier.


The identifier is defined by openxpki, so you wont get it from openssl.
You can use "openxpkiadm certificate id --file <certificate>" to get the 
identifier from a PEM encoded certificate.

But the best way would be to import the certificate with its full chain, just start with 
above import command using the root certificate file and proceed with all further chain 
certificates. If this is not doable for you, just set the identifier to any non-empty 
value together with "force-issuer". Note that this might led to unexpected 
behaviour if you need to build the chain for this certificate. Perhaps you can share what 
you intend to do, so I can give a better advice.

best regards

Oliver

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users



--
Protect your environment -  close windows and adopt a penguin!

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users

Reply via email to