Re: [OpenXPKI-users] AWS CloudHSM?

2024-01-17 Thread Martin Bartosch via OpenXPKI-users
Hi,

> Thanks it mostly did the trick – but still some issues. It seems token 
> rollover didn’t work. The crl issuance is trying to use casigner-1, but alias 
> with current cert is for casigner-2.
>  I also verified with openssl that crl issuance does work  manually.
>  Maybe this is a novice error, but I gathered from the docs that token 
> rollover is automatic?

Maybe a generic description of the process will help understand what is going 
on.

CA rollover is automatic in OpenXPKI if configured correctly.

The system basically does the following for certificate issuance (rollover):
- the system generates a list of all currently valid certsign tokens have been 
configured for the PKI Realm
- the token with the highest NotBefore date is selected at runtime for 
certificate issuance

For CRL generation, it is slightly different: the system iterates through all 
currently valid certsign tokens and issues CRLs for all of them.


The basis for making this work is that OpenXPKI must be able to associate a 
given certsign token/issuing certificate with the correct private key.

The certsign token is defined by declaring it via openxpkiadm and setting an 
internal database that identifies a particular certificate as "special". This 
is done by assigning an alias to that certificate, normally also a generation 
ID is also assigned which caters for CA generations. If not implicitly 
specified, the generation starts at 1 and is auto-incremented on each 
subsequent import.

The mapping to a private key happens via the configuration in crypto.yaml. 
After the system has figured out (implicitly or explicitly) which certsign 
token it shall use, it looks up how to access the private key for that token. 
The private key that is the result of this inference is then used for the 
private key operation.

This means that the definition in crypto.yaml must be consistent with the 
assignment of certsign tokens via openxpkiadm. 
In practice this primarily means that the PKI admin must make sure that the 
certsign token is set with the correct generation ID, and that the resulting 
token alias (consisting of group name and generation) is resolved to the 
matching private key.

The behavior you observed seems to indicate that the system references an 
incorrect private key for the certsign token. How this did happen in your case 
depends on the administrative actions that happened before and how the private 
keys are referenced and used.

Cheers

Martin+



___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users


Re: [OpenXPKI-users] AWS CloudHSM?

2024-01-17 Thread henri.sundelin
Thanks it mostly did the trick – but still some issues. It seems token rollover 
didn’t work. 

The crl issuance is trying to use casigner-1, but alias with current cert is 
for casigner-2.

 

I also verified with openssl that crl issuance does work  manually.

 

Maybe this is a novice error, but I gathered from the docs that token rollover 
is automatic?

 

Br,

//HS

 

--
% openxpkicmd --realm democa crl_issuance

 

In catchall.log:

2024/01/17 16:58:30 openxpki.auth.INFO Login successful (user: Anonymous, role: 
System) [pid=45218|sid=wQyR|pki_realm=democa]

2024/01/17 16:58:30 openxpki.application.INFO start crl issue for ca 
casigner-1, workflow 5119 
[pid=45218|user=Anonymous|role=System|sid=wQyR|wftype=crl_issuance|wfid=5119|pki_realm=democa]

2024/01/17 16:58:31 openxpki.system.ERROR OpenSSL error: engine "cloudhsm" set.

Using configuration from /var/tmp/openxpki45218q4_fnUUO/openssl.cnf

CA certificate and CA private key do not match

 

However the aliases show:

 

% openxpkiadm alias --realm democa

=== functional token ===

vault (datasafe):

  Alias : vault-2

  Identifier: VkhM86XJuv84LuRmtw4eHHkL25M

  NotBefore : 2024-01-17 12:56:38

  NotAfter  : 2024-02-16 12:56:38

 

ratoken (scep):

  not set

 

casigner (certsign):

  Alias : casigner-2

  Identifier: iLC-b4Fn9EeZehIJqZ51gE3TGkU

  NotBefore : 2024-01-17 13:21:48

  NotAfter  : 2034-01-17 13:21:48

 

ratoken (cmcra):

  not set

 

=== root ca ===

current root ca:

  Alias : root-1

  Identifier: 5zenJ7c7uwUc1cOr09_-eFIaLKw

  NotBefore : 2023-12-20 09:02:08

  NotAfter  : 2053-12-12 09:02:08

 

upcoming root ca:

  not set

 

 

From: Oliver Welter  
Sent: Wednesday, January 17, 2024 4:52 PM
To: openxpki-users@lists.sourceforge.net
Subject: Re: [OpenXPKI-users] AWS CloudHSM?

 

Hi Henri,

from the docs of the module ;)

 

=head1 Configuration

 

Set I and set the I attribute to point to

the fake-key file (supports local file or datapool as with plain

OpenSSL software keys).

best regards

 

Oliver

 

On 17.01.24 14:38, henri.sunde...@iki.fi   wrote:

Is it possible to configure OpenXPKI with AWS CloudHSM Dynamic Engine?
 
I tried something like this in crypto.yaml:
 
casigner:
backend: OpenXPKI::Crypto::Backend::OpenSSL
key: /etc/openxpki/ca/subca_private_ref.pem
engine: cloudhsm
engine_section: |
  engine_id = cloudhsm
  MODULE_PATH = /opt/cloudhsm/lib/libcloudhsm_openssl_engine.so
  #PIN = __PIN__
  init = 0
engine_usage: 'ALWAYS'
key_store: OPENXPKI
shell: /opt/openssl/bin/openssl
randfile: /var/openxpki/rand
wrapper: ''
secret: signer
 
..but that fails to the fact it tries to download a perl module called
cloudhsm.pm. 
 
The main difference to PKCS11 is that the private key reference is a fake
private key pem file. There are no options to be passed, the HSM pin is
expected to be in env variable.
In practice I believe you need to just pass "-engine cloudhsm" to openssl
for thus engine to work.
 
Br,
//HS
 
 
 
 
 
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net 
 
https://lists.sourceforge.net/lists/listinfo/openxpki-users
 

-- 
Protect your environment -  close windows and adopt a penguin! 
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users


Re: [OpenXPKI-users] AWS CloudHSM?

2024-01-17 Thread Oliver Welter

Hi Henri,

from the docs of the module ;)

=head1Configuration
Set Iand set the Iattribute to point to
the fake-key file (supports local file or datapool as with plain
OpenSSL software keys).

best regards

Oliver

On 17.01.24 14:38, henri.sunde...@iki.fi wrote:

Is it possible to configure OpenXPKI with AWS CloudHSM Dynamic Engine?

I tried something like this in crypto.yaml:

casigner:
 backend: OpenXPKI::Crypto::Backend::OpenSSL
 key: /etc/openxpki/ca/subca_private_ref.pem
 engine: cloudhsm
 engine_section: |
   engine_id = cloudhsm
   MODULE_PATH = /opt/cloudhsm/lib/libcloudhsm_openssl_engine.so
   #PIN = __PIN__
   init = 0
 engine_usage: 'ALWAYS'
 key_store: OPENXPKI
 shell: /opt/openssl/bin/openssl
 randfile: /var/openxpki/rand
 wrapper: ''
 secret: signer

..but that fails to the fact it tries to download a perl module called
cloudhsm.pm.

The main difference to PKCS11 is that the private key reference is a fake
private key pem file. There are no options to be passed, the HSM pin is
expected to be in env variable.
In practice I believe you need to just pass "-engine cloudhsm" to openssl
for thus engine to work.

Br,
//HS





___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users


--
Protect your environment -  close windows and adopt a penguin!
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users


[OpenXPKI-users] AWS CloudHSM?

2024-01-17 Thread henri.sundelin
Is it possible to configure OpenXPKI with AWS CloudHSM Dynamic Engine?

I tried something like this in crypto.yaml:

casigner:
backend: OpenXPKI::Crypto::Backend::OpenSSL
key: /etc/openxpki/ca/subca_private_ref.pem
engine: cloudhsm
engine_section: |
  engine_id = cloudhsm
  MODULE_PATH = /opt/cloudhsm/lib/libcloudhsm_openssl_engine.so
  #PIN = __PIN__
  init = 0
engine_usage: 'ALWAYS'
key_store: OPENXPKI
shell: /opt/openssl/bin/openssl
randfile: /var/openxpki/rand
wrapper: ''
secret: signer

..but that fails to the fact it tries to download a perl module called
cloudhsm.pm. 

The main difference to PKCS11 is that the private key reference is a fake
private key pem file. There are no options to be passed, the HSM pin is
expected to be in env variable.
In practice I believe you need to just pass "-engine cloudhsm" to openssl
for thus engine to work.

Br,
//HS





___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users


Re: [OpenXPKI-users] enrollment client using Windows CNG API - SCEP or EST

2024-01-17 Thread Oliver Welter

Hi Jeremy,

if a commercial product is an alternative: we have rewriten the "old" 
perl based CertNanny project in GoLang which is a nicely featured 
enrollment client that works perfectly with OpenXPKIs RPC interface (and 
also other CAs using SCEP/EST), runs on Linux/Mac/Win and comes with a 
PowerShell interface for key management on the client.


best regards

Oli

On 17.01.24 01:11, Jeremy Jackson wrote:
And a couple of hours of Googling later, an SCEP client written in 
PowerShell:


https://www.powershellgallery.com/packages/PSCertificateEnrollment/1.0.0/Content/Functions%5CGet-NDESCertificate.ps1 



On 2024-01-16 17:36, Jeremy Jackson wrote:

Windows CNG looks great for using Virtual Smart Cards for domain logins.

Here is some recent work on adding CNG to OpenSSL 3

https://github.com/Lipovlan/cng-openssl-provider

I have only been able to find "sscep" which uses OpenSSL 1.1 CAPI Engine.

Are there any other known enrollment clients that work with OpenXPKI?

Thanks,

Jeremy



___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users



___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users


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



___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users