Re: [OpenXPKI-users] How are IP addresses added as Alternative Subject Names?
Hi, > Does OpenXPKI support IP addresses as a SubjectAlternativename? > > > On Fri, May 10, 2024 12:00, James B. Byrne wrote: > > How does one add an IP dotted quad as an alternate subject name when a signing > certificates? When added through the webui they appear as > DNS:xxx.xxx.xxx.xxx. > I amused to seeing IP:xxx.xxx.xxx.xxx in the SAN in such cases. In the unlikely case an IP address is actually needed in a certificate a profile this SAN type can be referenced via san_ipv4 in a subject style. Examples are included in the community configuration in the "advanced" subject style, aptly named as "Extended naming (expert use only)" in the GUI. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Allow additional Elliptic Curves
Hi, > I have created a csr using the elliptic curve secp256k1. When I copy this csr > in the web interface and try to request a certificate, I get this error: > "Used key parameter is not allowed by policy (curve_name: 1.3.132.0.10)" > > When I do the exact same thing but using the curve secp512r1, I don't have > this problem. > > Further, I edited a few things in the file democa/profile/default.yaml: > • I added the curve secp256k1 in the section ec: curve_name: > • at the end of the file I added the string > "#I18N_OPENXPKI_UI_KEY_CURVE_NAME_SECP256K1" > But, this does not seem to solve the problem. > > Do I have to make some additional changes somewhere else? Have a look at the comments above the key constraints setting in config.d/realm.tpl/profile/default.yaml ... ec: # those names are used for validation and to render the # option lit when server key generation is allowed # The preset is the recommended list from RFC5480 # The possbile "named" curves are limited by the ones supported # by Crypt::PKCS10 at the moment. For NIST P-192/256 you can use # either the secpXXXr1 or primeXXXv1 alias curve_name: - prime256v1 - secp384r1 - secp521r1 ... As mentioned in the comment, only named curves supported by Crypt::PKCS10 are accepted here. If you check the documentation of this module you will find that the curve secp256k1 is not supported by Crypt::PKCS#10. If you feel you need it (and/or possibly others), I suggest you take the time to collect a list of OIDs and curve names and submit a pull request via https://github.com/openxpki/Crypt-PKCS10 BTW, adding the string "#I18N_OPENXPKI_UI_KEY_CURVE_NAME_SECP256K1" literally does nothing (short of informing the Gnu GetText about a possible translation). Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] EST Endpoint / RFC 7030
Hi, > For authenticated EST the OpenXPKI documentation says: Use the UI to obtain a > TLS Client certificate with the application name *pkiclient* > > I don't understand in which field of the X.509 certficate should the > "application name" go. Our default configuration ships with the following EST endpoint configuration: config.d/realm.tpl/est/default.yaml: label: EST Default Endpoint authorized_signer: rule1: # Full DN subject: CN=.+:pkiclient,.* ... This basically means "extract the CN from the subject and check if it ends with :pkiclient". This can be used to perform some sort of authorization for the "enrollment on behalf" case in which a client certificate is used to obtain multiple certificates with different subjects. Basically this feature can be used to centralize automatic issuance for certificates of other subscribers (and needs a properly configured OpenXPKI EST/SCEP/RPC endpoint). In order to facilitate issuing a certificate with subject with CN=foo:pkiclient, O=... can be created during the request process. Our default GUI configuration provides a field "Application Name". If this is non-empty, the subject rendering rule in the default configuration will append ":ApplicationName" to the CN value. The purpose of this is to be able to have multiple distinct certificates for one single host (for different purposes). One of these purposes could be enrollment-on-behalf, in which case you could input "pkiclient" as application name, giving you a TLS Client certificate which would match above rule. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Cannot generate a new certificate from external csr
James, > I generated a new csr from the private key: > > openssl req -new -key 2016002C.key -out 2016002C_20240507.csr No, you regenerated the same CSR from the same private key. > When I paste the entire .csr into openxpki webui I get this error: > > > The uploaded key was found to be used already by another certificate request > but it is not allowed to certify the same key twice. > > 1. What uploaded key does this message refer? To the public key in the (same) CSR you used before. > > 2. What specific series of events causes this message to be issued? The PKI design decision we implemented in OpenXPKI in order to prevent exactly this. > 3. What am I misapprehending with respect to issuing certificates for > existing > hosts? One of the reasons of having a NotAfter date in an X.509 Certificate is to limit exposure and active use of the associated private key. By default, OpenXPKI enforces this idea by not allowing reuse of the same private key for newly issued certificates. This is a good idea, but you can, of course, disable that if you so choose. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] SSL
Hi, > How can the registration officer set the validity? Well, click on "Edit Validity" on a PENDING request. > How could I create a second profile most effectively? I know I need to > expand the profile, but how should I configure it best? Create a copy of the profile's YAML file for which you want to have a variant and edit what you would like to change, in this case the certificate validity. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] SSL
Ali, > Thank you, but I have found my mistake Would you mind sharing your experience so others can benefit from your resolution in case they are facing a similar problem? > Another question > Is there a possibility under "realm/democa/profile/default" to select the > validity between 1 year and 6 months. So that the user himself chooses > whether he wants to have 1 year or 6 months validity. The Registration Officer can modify the validity of a pending request before approving/issuing the certificate. Selection of different validities during the request process (by the user) is not available in the Community Edition, but this feature exists in the Enterprise Edition. A simple workaround is to define two different profiles with the desired validities and naming them appropriately, so the user can select the validity by choosing the profile. It's not a pretty solution but will work. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] How is an OpenXPKI generated private key exported?
James, > My question was imprecise. I had in mind a batch/cli type solution. After > further research this is what I am attempting to use. > openxpkicli --realm=hll_ca2016 get_private_key_for_cert \ > --param identifier='Lik1K_AGi-RDqOiNxjmptAh-4-w' \ > --param password='F990NCtO' \ > --param passout='' \ > --param nopassword=TRUE \ > --param format=PKCS8_PEM > Error: Error while executing API command >Attribute (identifier) is required Retry using --arg instead of --param. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] How is an OpenXPKI generated private key exported?
James, > I created csr where the option to create a private key was selected. How is > the private key created for this csr exported from openxpki? Click on the Certificate. Choose Action -> "Download private key/keystore (PKCS12/PKCS8/Java)" Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] openxpkicli import_certificate
James, > I have successfully imported an existing certificate into the hll_ca2016 > realm, > finally. > > openxpkiadm certificate list -v -v --realm hll_ca2016 --all > > Certificates in hll_ca2016: > > Identifier: 76QCIA3aO9WOjkW6g2SAGQXoATI >Subject: > DC=ca,DC=harte-lyne,DC=hamilton,C=CA,ST=Ontario,L=Hamilton,O=Harte & Lyne > Limited,OU=Networked Data Systems,CN=inet11.hamilton.harte-lyne.ca >Issuer DN: > DC=ca,DC=harte-lyne,C=CA,ST=Ontario,L=Hamilton,O=Harte & Lyne > Limited,OU=Networked Data Services,CN=CA_HLL_ISSUER_2016 >Chain: > 76QCIA3aO9WOjkW6g2SAGQXoATI -> Yh03GEV0ZGEqIGMf-fxZ3lErPmk -> > CYQ4rXzn4X14_pPNKi8_Pq-Ywg8(complete) > > However, this certificate does not appear in webui, unless it is searched for > by ID. The certificate is expired. Nonetheless, I believe that expired > certificates issued by a CA should continue to be reported. What is the > reason > that this certificate does not show up in 'my certificates' list or returned > when a general search for all certificates is preformed? You asked exactly the same question a few days ago: https://sourceforge.net/p/openxpki/mailman/message/58756353/ And Oliver provided the accurate answer: https://sourceforge.net/p/openxpki/mailman/message/58756390/ Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] openxpkicli import_certificate
James, > For the 'openxpkicli import_certificate' command there is a additional > parameter named 'profile' which takes a string argument. Is this string a path > to a file; or just the name of a file; or something else? Well, it's the profile name... In terms of the OpenXPKI configuration tree, this value references a leaf node below the "profile" node of a realm. In case of our published example YAML configuration layout (courtesy of Config::Merge), this also happens to be a file name in the profile directory of the realm. > > openxpkicli --realm hll_ca2016 \ >--filearg data=bare_20160001.pem \ >--param pki_realm='hll_ca2016' \ >--param update=1 \ > import_certificate > > Is the profile parameter significant in placing an imported certificate into a > specific realm? I don't understand the question. If you want to associate the imported certificate with a profile, you can specify it as an option for the import_certificate API function. > Is the default.yaml a valid profile for the purpose of importing a certificate > into a specific realm? No, as the name suggests it contains the common defaults for all other defined profiles. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Mapping openssl cnf options to openxpki yaml profiles
James, > I have been struggling with the yaml profile mapping of certificate extensions > to openxpki profiles. I need some examples or a profile node key legend to > assist me in understanding how this works. I think the example configuration in the configuration repository is pretty self explanatory. Please take your time to look at it, understand it and map it to your use case. You will find it is not that hard. Also, I recommend to take this as an opportunity to clean up your existing certificate profile, you seem to have a lot of unnecessary legacy cruft in your existing certificates which I would recommend to get rid of. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Generate and publish a CRL
James, > There is no /var/www/ directory on FreeBSD as shipped. Instead the html root > is /usr/local/www/. I created /usr/local/www/download/ > > # ll -d /usr/local/www/download > drwxr-xr-x 2 root wheel 2 Apr 4 12:39 /usr/local/www/download > ... > > But still get the same result. > > 2024/04/04 14:05:33 9215 Publication failed for target disk-der, requeuing > 2024/04/04 14:05:33 9215 Publication failed for target disk-pem, requeuing > 2024/04/04 14:05:33 9215 Retry exceeded on action capub_publish_cacert > > What needs to be changed? Check yo staging. Uh, permissions. Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unable to load key from datapool;
James, > openxpkicli --realm hll_ca2016 --filearg data=hllcerts/20160001.pem > import_certificate > Error: Error while executing API command >Attribute (data) does not pass the type constraint because: ''Certificate: >Data: >Version: 3 (0x2) >Serial Number: 538312705 (0x20160001) >Signature Algorithm: sha512WithRSAEncryption > > I checked the certificate using: > > openssl x509 -text -noout -in hllcerts/20160001.pem > > and it is a valid pem encoded certificate. What am I missing? The file you are trying to import is not a pure PEM cert but contains leading text, and thus the input parameter is not passing the input data validation step. openssl x509 parses this just fine, but the API requires a pure PEM block. This is not the same. Verify with cat hllcerts/20160001.pem If the output is anything more than a pure - BEGIN CERTIFICATE - - END CERTIFICATE - then this is your problem. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] EST renewal/reenrollment
Hi, > 5- I do get authenticated through basic auth AND through the certificates i'm > passing to cURL. > But I keep getting back the same certificate. > No workflow is triggered. > And in EST.log > INF authenticated client DN: CN=same cn,DC=Test > Deployment,DC=OpenXPKI,DC=org [pid=91|ep=[undef]] > > 6- I thought it was my authentication stack causing the issue (using http > basic), so I reversed it back to the default (anonymous), and I still don't > get the renawal mode, just fetching the same certificate. When receiving an enrollment request via any of its enrollment interfaces OpenXPKI distinguishes initial enrollment, renewal and enrollment on behalf mode and branches into the respective branch of the enrollment workflow. You can see which path is chosen by examining the enrollment workflow instance and its context. If you send the same CSR (based on the same private key) to an enrollment interface, you will get back the existing certificate if the enrollment workflow for this key was previously successfully executed. If you wish to perform a renewal, you need to generate a new private key and a new certificate request based on that new key. In order to qualify as a renewal from the viewpoint of OpenXPKI, the renewal request must be authenticated by the old, existing certificate and key (and the subject must match). In your example this means that you would have to call curl with certificate and key option pointing to the old certificate. Also, the existing certificate validity is considered by the enrollment workflow. Depending on configuration, the request may only be accepted if a certain remaining validity of the existing certificate is not exceeded. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] 1 secret groups not available
James, > openxpkiadm alias \ > --realm "hll_ca2016" \ > --token certsign \ > --file /CA_HLL_ROOT_2016/certs/02.pem \ > --key /CA_HLL_ROOT_2016/private/keys/02.key.aes256 This command - imported 02.pem as the first (a "--generation 1" is implicit when you import the very first token) signer token in realm hll_ca2016 - also imported 02.key.aes as the corresponding signer key for this token The system automatically created the signer token ca-signer-1 as one instance of the ca-signer token group. You can import additional signers a few years down the road to perform seamless CA rollovers in your realm, if you don't specify --generation they will be assigned the token aliases ca-signer-2, ca-signer-3 etc. > This is what I have in crypto.yaml ... > token: > default: > backend: OpenXPKI::Crypto::Backend::OpenSSL > > # Template to create key, available vars are > # ALIAS (ca-signer-1), GROUP (ca-signer), GENERATION (1) > # KEY_IDENTIFIER (00:AA:BB...), IDENTIFIER (aGSNY1Z...) > key: /usr/local/etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem ... > > # Default value for import, recorded in database, can be overriden > secret: default > > ca-signer: > inherit:default > key_store: DATAPOOL > key:"[% ALIAS %]" > > > I infer from this error message: > > 2024/03/22 08:58:12 ERROR I18N_OPENXPKI_TOOLKIT_COMMAND_FAILED; __COMMAND__ => > OpenXPKI::Crypto::Backend::OpenSSL::Command::pkcs7_sign, __ERRVAL__ => > I18N_OPENXPKI_CRYPTO_CLI_EXECUTE_FAILED; __COMMAND__ => cms -sign -binary > -nosmimecap -outform PEM -nodetach -in /var/tmp/openxpki7068rAhBRK43 -inkey > /var/tmp/openxpki7068HnLhAvaK/ca-signer-1 -signer > /var/tmp/openxpki7068wnbNYH_K > -out /var/tmp/openxpki7068BT1d_Hs4 -passin env:pwd, __EXIT_STATUS__ => 512 > [pid=7068|sid=IBVP] > > That the issue lies in the configuration of crypto.yaml. No, it indicates that the secret group "default" does not unlock the CA key for ca-signer-1 in the datapool. > I do not grasp the employment of tokens. The error message refers to > ca-signer-1. Is this a token name? If so, does it have to be explicitly > named > in crypto.yaml or does the openxpki software look for ca-signer? See above. ca-signer is the token group. ca-signer-1 is a token instance in this token group. > Assuming that ca-signer is searched for then what is the value returned by "[% > ALIAS %]"? Does this reference get used to SEARCH in the RDBMS? What is > returned? The key itself or the path to the key file? Maybe we did not explain this properly in one of the previous posts. In your config > key_store: DATAPOOL > key:"[% ALIAS %]" tells the system to look in the datapool and retrieve the private key by its alias from the datapool. During the import of the private key in the above openxpkiadm command the private key was read and stored in the datapool. This is not mandatory, if it confuses you it can also be placed in the file system. In that case simply don't override key_store in the ca_signer definition, and the key will be referenced from the default location specified in token.default. > When the 'openxpkiadm alias' command receives the '--key > /CA_HLL_ROOT_2016/private/keys/02.key.aes256' argument are the contents of > that > file stored in the DB or the path to the key file? Depends on the token configuration. If key_store: DATAPOOL is set, the key is stored in the datapool. If key_store: OPENXPKI is set, the key is referenced from the file system. You can deposit they key in the file system yourself (and leave out --key during import) or have openxpkiadm write the key to the file system. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
Hi James, > This is the diff between the current config.d and the original before any > changes were made. > > # git diff -G. hllv1.00 -- --follow config.d > diff --git a/config.d/realm.tpl/crypto.yaml b/config.d/realm.tpl/crypto.yaml > index 95614f5..bda48a1 100644 > --- a/config.d/realm.tpl/crypto.yaml > +++ b/config.d/realm.tpl/crypto.yaml > @@ -15,7 +15,8 @@ token: ># Template to create key, available vars are ># ALIAS (ca-signer-1), GROUP (ca-signer), GENERATION (1) ># KEY_IDENTIFIER (00:AA:BB...), IDENTIFIER (aGSNY1Z...) > -key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > +# key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > +key: /usr/local/etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > ># possible values are OpenSSL, nCipher, LunaCA >engine: OpenSSL > @@ -42,7 +43,8 @@ token: > > vault: >inherit: default > -key: /etc/openxpki/local/keys/[% ALIAS %].pem > +# key: /etc/openxpki/local/keys/[% ALIAS %].pem > +key: /usr/local/etc/openxpki/local/keys/[% ALIAS %].pem > > ratoken: >inherit: default > @@ -58,6 +60,13 @@ token: > > # Define the secret groups > secret: > + > +ca-signer: > +label: Secret group for certsign Token > +export: 1 > +method: literal > +value: "democa" > + >default: ># this let OpenXPKI use the secret of the same name from system.crypto ># if you do not want to share the secret just replace this line with > @@ -69,4 +78,4 @@ secret: >label: Secret group for RA Token >export: 1 >method: literal > -value: root > \ No newline at end of file > +value: root Yep, that's the problem. In the original default crypto.yaml we find ... # The actual token setup token: default: ... # Default value for import, recorded in database, can be overriden secret: default ... # use ALIAS as key as it makes debug and management easier ca-signer: inherit: default key_store: DATAPOOL key: "[% ALIAS %]" ... # Define the secret groups secret: default: # this let OpenXPKI use the secret of the same name from system.crypto # if you do not want to share the secret just replace this line with # the config found in system.crypto. You can create additional secrets # by adding similar blocks with another key import: 1 This means that the ca-signer token inherits from the default token configuration which references the "default" secret group. This "default" secret group is imported from the global configuration in config.d/system/crypto.yaml. There we find: secret: default: label: Global secret group export: 0 method: literal value: root You added a new literal secret group "ca-signer" with the value "democa" to your token configuration. Now, the error in the configuration is that you obviously assumed that by defining a secret group with the same name as the signer token will link this. This is not the case. Your new secret group was defined but is never used. In order to make this work as you intend you need to do one of the following: 1. in your default token configuration change the secret definition to the correct secret group reference: token: default: ... secret: ca-signer OR 2. change the password in the "default" secret group from "root" to "democa" OR 3. change the CA key passphrase to "root" OR 3. enable passphrase entry via the GUI and use the GUI to enter your passphrase "democa" after startup Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
Hi James, > This is the diff between the current config.d and the original before any > changes were made. > > # git diff -G. hllv1.00 -- --follow config.d > diff --git a/config.d/realm.tpl/crypto.yaml b/config.d/realm.tpl/crypto.yaml > index 95614f5..bda48a1 100644 > --- a/config.d/realm.tpl/crypto.yaml > +++ b/config.d/realm.tpl/crypto.yaml > @@ -15,7 +15,8 @@ token: > # Template to create key, available vars are > # ALIAS (ca-signer-1), GROUP (ca-signer), GENERATION (1) > # KEY_IDENTIFIER (00:AA:BB...), IDENTIFIER (aGSNY1Z...) > -key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > +# key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > +key: /usr/local/etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > > # possible values are OpenSSL, nCipher, LunaCA > engine: OpenSSL > @@ -42,7 +43,8 @@ token: > > vault: > inherit: default > -key: /etc/openxpki/local/keys/[% ALIAS %].pem > +# key: /etc/openxpki/local/keys/[% ALIAS %].pem > +key: /usr/local/etc/openxpki/local/keys/[% ALIAS %].pem > > ratoken: > inherit: default > @@ -58,6 +60,13 @@ token: > > # Define the secret groups > secret: > + > +ca-signer: > +label: Secret group for certsign Token > +export: 1 > +method: literal > +value: "democa" > + > default: > # this let OpenXPKI use the secret of the same name from system.crypto > # if you do not want to share the secret just replace this line with > @@ -69,4 +78,4 @@ secret: > label: Secret group for RA Token > export: 1 > method: literal > -value: root > \ No newline at end of file > +value: root Yep, that's the problem. In the original default crypto.yaml we find ... # The actual token setup token: default: ... # Default value for import, recorded in database, can be overriden secret: default ... # use ALIAS as key as it makes debug and management easier ca-signer: inherit: default key_store: DATAPOOL key: "[% ALIAS %]" ... # Define the secret groups secret: default: # this let OpenXPKI use the secret of the same name from system.crypto # if you do not want to share the secret just replace this line with # the config found in system.crypto. You can create additional secrets # by adding similar blocks with another key import: 1 This means that the ca-signer token inherits from the default token configuration which references the "default" secret group. This "default" secret group is imported from the global configuration in config.d/system/crypto.yaml. There we find: secret: default: label: Global secret group export: 0 method: literal value: root You added a new literal secret group "ca-signer" with the value "democa" to your token configuration. Now, the error in the configuration is that you obviously assumed that by defining a secret group with the same name as the signer token will link this. This is not the case. Your new secret group was defined but is never used. In order to make this work as you intend you need to do one of the following: 1. in your default token configuration change the secret definition to the correct secret group reference: token: default: ... secret: ca-signer OR 2. change the password in the "default" secret group from "root" to "democa" OR 3. change the CA key passphrase to "root" OR 3. enable passphrase entry via the GUI and use the GUI to enter your passphrase "democa" after startup Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
Hi James,
> 2024/03/13 08:16:31 ERROR OpenSSL error: Using configuration from
> /var/tmp/openxpki28821VniVdpfp/openssl.cnf
> unable to load CA private key
> . . .
>
> I guess that this is the problem: unable to load CA private key
Yep.
> The realm was created using:
>
> openxpkiadm alias \
> --realm "democa" \
> --token certsign\
> --file
> /root/CLCA/CAS/democa/certs/1A84E8FBE282453D5F22038C58A89786BCD6CCAC.pem \
> --key /root/CLCA/CAS/democa_i/private/democa_i_key.pem
>
> openxpkicli get_token_info --realm=democa --arg alias=vault-1
> {
> "key_name" : "/usr/local/etc/openxpki/local/keys/vault-1.pem",
> "key_secret" : 1,
> "key_store" : "OPENXPKI",
> "key_usable" : 1
> }
>
> I have verified that the private key password provided in
> config/realm/democa/crypto.yaml is correct:
>
> . .
> ca-signer:
>inherit: default
>key_store: DATAPOOL
>key: "[% ALIAS %]"
> . . .
> secret:
>
>ca-signer:
>label: Secret group for certsign Token
>export: 1
>method: literal
>value: "democa"
1. the output of openxpkicli get_token_info (file in file system) is not
consistent with your configuration (key in datapool). I have no idea why,
because I cannot see more details on your system, but to me it looks like the
ca-signer token configuration is not the config the system is using
2. the config snippet is missing the definition for "default" in crypto.yaml
where I assume the secret group is defined. If that does not match the secret
group you seemingly intend to use for your ca signer tokens (which you named
"ca-signer") then the passphrase will not be set correctly. Again, without
being able to see more or your config it is impossible to tell.
2a. a fixed value for a CA key is not a good idea
Bottom line: your system cannot access the private key, and this is either a
permission problem or a problem with the CA passphrase.
Cheers
Martin
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
Hi James, > __EXIT_STATUS__ => 256 == Searching for Openssl error codes the number 256 > comes up as related to an unsupported cipher. Where is the cypher being > specified? The exit status is shifted left by 8 bit by the execution wrapper in OpenXPKI, so the actual return code is 256 >> 8 == 1, and 1 is the generic OpenSSL error message. You should get more information about the error in the openxpki.log file. I suspect something is wrong with the CSR or the CA key, but the details you posted do not contain sufficient detail to tell what exactly went wrong. Is your CA set up correctly? Are you able to create a CRL? Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Without AES256
Hi, > Is there also a possibility when I create certificates that the certificates > are stored directly on the server on which openxpki is running? Your question is not specific enough to let us understand what you actually want to achieve, and for this reason the answer is a qualified "yes". Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Without AES256
Hi, > Could you tell me in which workflow I cloud define the fixed password? Well, that's the workflow you are using for requesting the certificate, most likely certificate_signing_request_v2 In this workflow you will find an activity which is conveniently called generate_key... Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Missing index.html
James, On a Unix system, a user needs execute permission in order to enter a directory (not read). Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Missing index.html
Hi,
> I have discovered that my literal reading of README.md and the Quickstart
> guide
> led me to copy the /usr/local/share/examples/openxpki/htdocs/ directory to
> /var/local/www/openxpki/ whereas it appears that I instead should have copied
> the contents thereof. This I have now done and I get a different error.
>
> I now see the openxpki logo on a grey page with the following error message
> box:
>
> Application Error
>
> [
> "There was an error while processing the data received from the server: ",
> {}
> ]
>
> This probably means that I have misconfigured, or failed to configure
> something
> else.
>
> Any clues as to what that may be?
Is mod_fcgid enabled in Apache? Check if the fcgi scripts are actually
executed, if mod_fcgid is not enabled you will see the raw output of the CGI
script in the development console or your browser.
Check the web server error log file for hints.
If fcgi is enabled, check the web server log files, typically at
/var/log/openxpki/webui.log, you should see log messages there.
If none are to be seen,
touch /var/log/openxpki/webui.log
chown WEBSERVER-RUNTIME-USER /var/log/openxpki/webui.log
chmod 600 /var/log/openxpki/webui.log
And retry.
While you are at it, also create scep.log, rpc.log, est.log with the same
owner/permissions there.
HTH
Martin
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] examples of crypto.yaml desired.
Hi, Some background information may be useful here: When importing a certificate into the OpenXPKI database, the system tries to build a certificate chain up to a know Root CA certificate. If no chain can be built, import is refused (there are ways to override this, though). For chain building, the system automatically references Root CA certificates from its entire database, from all PKI Realms. For chain building it does not matter where (in which realm) the Root CA certificate is actually located. Typically Root CAs are not managed by OpenXPKI, but rather in an offline environment, so normally there is no PKI Realm hosting the (active) Root CA. In that case Root CA certificates are normally only used to establish a trust relationship by relying parties, and they are *technically* not needed for the actual operation of a subordinate CA. We wanted to make sure that the resulting CA hierarchy is somewhat consistent, so when setting up an OpenXPKI PKI Realm as a subordinate Issuing CA, the system needs the corresponding Root CA certificate when importing the CA Signer token certificate. The Root CA certificate is - as mentioned - only used for chain building and trust management, and it may also be used/referenced by other PKI Realms. So the Root CA certificate has to be in the database somewhere. We decided that a "Null" PKI Realm is the proper place to import such certificates. Certificates in the "Null" Realm can be implicitly referenced by all other realms but do not serve an active purpose. Now some information I seem to get between the lines from your previous communication. I may be wrong, but you mentioned the Root CA key in the context of the OpenXPKI setup. This sounds a bit strange, as it seems to imply that you also run the Root CA as an OpenXPKI PKI Realm. We do not recommend to run a Root CA on an online system, but technically this works just fine. Now, if you actually have an active Root CA PKI Realm in which you issue Issuing CA certificates, this Realm also keeps the Root CA certificate. In this particular case, the Root CA certificate is already in the database, and other PKI Realms will automatically be able to reference is for completing certificate chains. Listing the signer certs in THIS Root CA realm will then show the Root CA certificate. In other words, in normal setups the Root CA certificates are imported into the null realm, because they are passively needed for chain building. In a case where an active Root CA realm exists, this is not necessary, as the system already knows the Root CA certificate from this realm. In addition, I noticed that you seem to have a year specification in the name of an Issuing CA. This may imply that you intend to add additional Realms for future "versions" of this Issuing CA. Although this works, this is not how we recommend to set up OpenXPKI, as it contains proper mechanisms to handle a seamless CA rollover within the same PKI Realm. You just import new signers to the Realm and it can live forever. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Display Names for Custom Profiles
Hi Mark, > I found the display names in "/etc/openxpki/contrib/i18n/en_US/openxpki.po" > file and added a new entry for msgid > "I18N_OPENXPKI_UI_PROFILE_TLS_SERVER_LABEL_5Y" with a msgstr of "TLS/Web > Server (5 years)". The translations in OpenXPKI are handled by Gnu Gettext. The following procedure should work: - leave openxpki.po untouched (it may get updated from upstream) - add a openxpki.po.local in the same directory, place your local translations there - if you specify existing translations in openxpki.po.local, they will be preferred over the existing ones in openxpki.po by the following procedure In order to activate the translations run msgcat --use-first openxpki.po.local openxpki.po | msgfmt -o openxpki.mo - Copy the resulting openxpki.mo file to /usr/share/locale/LANGUAGE/LC_MESSAGES/openxpki.mo Restart Apache (in some cases you also need to restart openxpki), and your new translations should be displayed properly. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Web Virtual Host not Working
Hi Mark, > root@certca:/var/www/openxpki# openxpkicmd --realm certca crl_issuance > Workflow created (ID: 255), State: SUCCESS > > But When I get to the portion of Adding the Webclient, once again following > the instructions, I do not see Apache start listening on port 443. > > root@certca:~# netstat -an | grep 443 > root@certca:~# > > I have created a self signed certificate and put them in the locations > specified in the document. > > root@certca:/etc/openxpki/tls# ls -R > .: > endentity private > > ./endentity: > openxpki.crt > > ./private: > openxpki.key > > I am not sure what I am missing, I see the openxpki.conf linked from > "sites-enabled" to "sites-available" in /etc/apache2 directory. > > Currently, because Apache is not listening on port 443, every connection is > understandably refused. It is quite likely that mod_ssl is not enabled in your Apache. Try a2enmod ssl and restart Apache. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Sscep problem
Hi, > I'm a bit further along now, I installed sscep via Github Link but now I get > the error message: > /sscep# ./sscep getca -c tmp/cacert -u http://domainorip/scep/scep > ./sscep: cannot open cert file for writing mkdir tmp and retry. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] AWS CloudHSM?
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] OpenSSL 1 vs 3 support?
Hi, > I noticed that the community edition has dependency to OpenSSL version 3. I > was wondering if OpenSSL 1 works as well, or is OpenSSL 3 a hard > requirement? OpenXPKI supports both versions. The reason that the debian package depends on OpenSSL 3 is that Debian ships this version by default. FYI, the OpenXPKI Enterprise Edition packages for Red Hat 8 and SuSE SLES 15 still reference (and use) OpenSSL 1, because both distributions still ship this version of OpenSSL. OpenSSL is mainly used for the actual certificate and CRL issuance operations within OpenXPKI. We are constantly working on reducing dependencies into OpenSSL, we have already replaced OpenSSL with a native solution to parse certificate requests and process SCEP messages. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Help
Hi, > When I check with "openxpkiadm alias --realm ..." my CA signer, Valut and > Root CA are displayed. Is that correct or not? Am I completely wrong or have > I overlooked something? Maybe it is correct, maybe it is not. It is not possible to help you if you do not provide useful information which would allow us to understand what you are doing. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Help
Hi > I get the message when I want to check "LOAD_NEXT_CA_CRL_GET_NEXT_CA_0" CRL. > On the Openxpki WebGui it shows me "No CRL found!" and my CA signer is > apparently offline. local CRL issuance within a PKI Realm only works if the CA signer tokens of this Realm are online, so make sure that this is the case before trying to proceed. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Multiple Private Keys for a single realm
Happy New Year everyone! > We are running a setup with OpenXPKI with a single Root CA (RSA private key) > and a couple of intermediate/subordinate CA (all with EC private keys). > > Now we have hit a problem where a 3rd party product should act as a separate > CA but still we want to maintain the trust back to our root ca. This is > working fine with our subordinate CA on other platforms, but this platform > requires the signing key being a RSA key and not a EC key. > > Now I can perfectly fine create a new realm with a RSA key (tested ok) > however, would it be possible to have multiple private keys on a single > realm? For example that our Sub CA will sign CSRs based on a RSA private key > with a RSA key and EC requests with the EC key? As you mentioned, OpenXPKI supports certificates with both EC and RSA keys, and this is generally true on all "certificate levels": The active Issuing CA within a PKI Realm can itself be based on an RSA or an EC key and it can issue EC or RSA certificates. Apart from that, OpenXPKI supports any number of Issuing CAs within one single PKI Realm. However, the idea here is that only one of these Issuing CAs is active at any given time, so this feature is used to support seamless Issuing CA rollovers where a newer Issuing CA completely takes over issuance of certificates and the older CAs within the Realm are in passive mode, issuing CRLs only. Now, if I understand you correctly you want to have two distinct Issuing CA certificates which are valid and concurrently active at the same time within a PKI Realm, with both actively issuing certificates. This is not supported with the standard workflows within OpenXPKI, and I don't see it as a feature that is useful in general. My recommendation is to use two different Realms with different Issuing CAs below the same Root CA instead. It is of course possible to modify/customize the workflows in a way that this would work, but this requires analysis, design and implementation to do this right (and my gut feeling is that while doing so some nasty gotchas might appear). Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] OpenxPKI Update
Hi Elias, > After updating our Debian server from version 9 to 11 and also updating the > OpenXPKI installation and configuration, I am encountering the following > problem: > openxpkictl[1592]: Please set database schema version! at > /usr/share/perl5/OpenXPKI/Server/Init.pm line 291. > Here is the database configuration: > (/etc/openxpki/config.d/system/database.yaml) > main: > debug: 1 > type: MariaDB > name: openxpki > host: localhost > #port: 3306 > user: openxpki > passwd: password > Can you help me correct the configuration? Best regards, Elias In version 3.26 we introduced a version indicator which will help us to address schema updates in the future more easily. Please read the file contrib/sql/UPGRADE.md in the configuration repository and perform the necessary updates on the database: https://github.com/openxpki/openxpki-config/blob/community/contrib/sql/UPGRADE.md Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Failed Action: csr_notify_pending - ERROR: requested value is not a scalar
Hi Maximillian, > Having some trouble with a new openxpki install using the docker image. I've > gotten most everything configured, but when I try to generate a CSR via the > webui, I get the following error: > > Unexpected error > This workflow was interrupted by an unexpected event, it will not continue > without a manual interaction. Please contact the support team! > Last Update > 2023-12-21 21:18:39 UTC > Failed Action > csr_notify_pending > Exception Message > requested value is not a scalar at > /usr/share/perl5/Connector/Builtin/Memory.pm line 74. at > /usr/share/perl5/OpenXPKI/Server/API2/Plugin/Workflow/Util.pm line 318. > > I've tried swapping out the profile I'm using with the tls_server.yaml > profile in the democa and that has the same issue. I've also swapped out the > default.yaml with the one from the democa and still, same issue. Not sure > what else I can set to default configs to get this working, but any help > would be appreciated. >From the GUI error message you posted something is not correctly configured >with regard to notification. Reading between the lines of your post I assume you did a certain amount of customization, possibly involving notification or metadata handling. However, without additional information such as technical log, log file contents and relevant configuration snippets it is unfortunately not possible to provide any assistance. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] CMC support in OpenXPKI ?
Hi Scott, > Does OpenXPKI support Certificate Management over Cryptographic Message > Syntax (CMC) ? > Yes, it does. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] private key attestation verification for enrollment
Hi Jeremy, > There is a draft RFC which proposes to add the capability to convey private > key attestation to an enrollment server: > > https://www.ietf.org/archive/id/draft-ietf-lamps-key-attestation-ext-00.html > > This covers all protocols and all attestation sources. I have been working > with Android KeyStore and KeyChain lately and this certainly seems possible > on the client end. > > I haven't looked at the other draft(s) mentioned in the above RFC, or for any > approved standards, but I hope this is enough to start a conversation. This is certainly an interesting development (and an official RFC covering this would have been really useful in one of my projects a decade ago...) As of today, this is still an IETF draft, not an RFC. Let's see how this develops, I would assume that we will see several years before it makes it to an offical RFC (if at all). Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] ACME support
Hi, > Hi Does openxpki has or plans to have a support for the ACME protocol ? We are currently working on a native ACME interface implementation and we plan to support ACME in the future. Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Run as non-root
Hi, > Has anyone successfully configured OpenXPKI to run as a non-root user? I'm > preparing an install for a hardened linux server. One of the requirements is > additional packages need to run as non-root. > > I've made some changes in the openxpkid.service file as well as the > system/server.yaml file and keep hitting permissions issues with the > openxpkid.pid or openxpkid.socket files. I've noticed that running as root > allows the pid and socket to change ownership when they're created but trying > to configure the permissions and directories still causes permission issues > whenever the openxpki is started. The OpenXPKI Daemon needs to be started as root because it needs to properly set the configured user and group ownership of the OpenXPKI Unix Domain Socket. Like any traditional, well-behaved Unix daemon OpenXPKI drops its privileges immediately after the setup and runs as the configured non-privileged runtime user. Proper design of permissions and ownership of this socket is absolutely required for a secure setup in which both the Apache frontend can communicate with OpenXPKI as well as OpenXPKI can properly communicate with crypto hardware. In particular with certain HSMs you will want to set up users, groups and permissions properly in order to secure the system. To summarize: Works as designed. Starting the daemon as non-root does not improve security, instead the system would be less secure if it were not started as root, because in that case one single user must be used for all system components. Cheers, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Looking for an open source PKI software manager
Hi Mike, > Will OpenPKI meet all of our needs? > Sempris needs a certificate management system, specifically for: > 1. AWS Lambdas > 2. Internal web sites > 3. Various internal services > The first (AWS) is the biggest challenge. We anticipate managing between > 100-200 different certificates. The AWS Certificate Manager (ACM) is one > option that can work, but we need to consider alternatives. > Please, advise. Thank you. One of the most powerful OpenXPKI features is its flexibility when it comes to integration with various infrastructure components. As Nick mentioned, the most straightforward approach for automation requirements is via one of the enrollment interfaces (SCEP, EST, the OpenXPKI-RPC interface). Our team has designed and implemented many OpenXPKI setups and integrated OpenXPKI in a large number of different environments, many of them with specific requirements towards infrastructure integration and certificate request process automation. If you are interested in professional cryptographic key management consulting and OpenXPKI support please get in touch with off...@whiterabbitsecurity.com Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] OpenXPKI woth YubiHSM2 - Unable to load module yubihsm_pkcs11
Hi, > Am 29.09.2023 um 04:08 schrieb Lixin Liu : > > I am using RHEL system which is not officially supported. But from what I > see, there are > only very minor difference. I have these: Just to clarify: The Community Edition is available as source code and packaged for Debian. However, OpenXPKI Enterprise Edition is available packaged for Red Hat Enterprise Linux, SuSE SLES and Ubuntu LTS. Any HSM that can successfully be used on the command line with OpenSSL via PKCS#11 should also work with OpenXPKI. How this exactly works depends on the HSM and its PKCS#11 implementation. Some hints: - it has already been mentioned, but make sure that any environment variables the driver needs is also set in OpenXPKI - personally, I very much prefer the RFC 7512 URI scheme for specifying PKCS#11 objects (keys) in the OpenXPKI configuration instead of the traditional (and somewhat obscure) slot notation. The GnuTLS p11tool is very useful in getting the proper information needed for a particular HSM. Otherwise the suggestions provided on the list should help get this up and running. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Active/Active Setup
Hi, > we are planning to setup up an active/active system over two geo locations. > Does anyone have experience with such a scenario and can share some best > practices? > We would otherwise testing db replication or setting up different signing > ca’s within the datacenters, but I would rather have this in a way to be able > to control duplicated certificates. Yes, active-active works without any problems with any number of worker nodes. For an active-active setup you need: - a redundant database, All OpenXPKI worker node need to access the same database instance - any number of OpenXPKI worker nodes. All worker nodes must have the same configuration. - the OpenXPKI web interface must be configured to store sessions in the database. For a long time this has been the default. - a load balancer which proxies all the worker nodes' web interfaces. The load balancer shall be configured in a way that for a given worker node topology queries get routed to the same worker node based on the Source IP (e. g. source IP hash). Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Integration Issue with Apache
Hi Chris, > 2023/09/01 16:28:21 ERR Error creating backend client Error while writing to > socket; __EVAL_ERROR__ => I18N_OPENXPKI_CLIENT_INIT_CONNECTION_FAILED; > __ERROR__ => Permission denied, __SOCKETFILE__ => > /var/openxpki/openxpki.socket [pid=2305|sid=[undef]] The OpenXPKI Web UI executes within the scope of the Apache server and needs read/write access to the OpenXPKI socket file. So, according to the above error message, please check permissions and ownership of the socket file. Obviously something is configured incorrectly, hence fix the Apache configuration (runtime user) and/or OpenXPKI server configuration accordingly. Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Integration Issue with Apache
Hi Chris, > Hi, I'm reaching out to the community seeking assistance with an issue I've > encountered during an integration process. Having recently upgraded my Apache > web server to the latest version from source, I referred to the documentation > and adjusted the openxpki.conf settings in alignment with the default Apache2 > configuration httpd.conf. However, when attempting to access the OpenXPKI web > interface, I'm consistently greeted with an "unknown application" error. I've > meticulously gone through the logs, and to my surprise, there are no error > entries recorded. I'm unable to pinpoint the root cause. As someone > relatively new to this endeavor, I'm open to learning from the community's > collective wisdom. I would greatly appreciate any insights you could provide. > It's possible that I've missed a step or overlooked a crucial configuration, > and your guidance could prove instrumental in resolving this matter. Without additional information it is very difficult to assess what went wrong. Have a look in the Apache error log, I would expect some enlightening information there. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] EST - invalid profile
Hi Thomas, >> Hi Thomas, >> invalid profile means that the NAME of the profile that the workflow tries >> to issue does not exist or is not in the list of the allowed endpoint >> profiles. > Where to find the ‘list of the allowed endpoint profiles’? In the profile_map section Enrollment Endpoint configuration: https://github.com/openxpki/openxpki-config/blob/community/config.d/realm.tpl/scep/generic.yaml#L84 Only profiles listed in this section are accessible via this particular endpoint. The key of this map is the name requested by the client. The corresponding value is the OpenXPKI profile within this realm that will be used to issue the certificate. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] EST and realm
Hi, > But I have an other question: is it possible to have an EST endpoint per > realm? OpenXPKI supports an arbitrary number of enrollment endpoints (EST, SCEP, RPC) per PKI Realm. Each of those can have different enrollment policies. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Issue new certificates for the Realm
Hi Gabriel, > I need to issue new realm certificates, both from ca-signer-1 and vault-1. > Could you tell me what commands I should execute to issue the certificates. If I understand you correctly you intend to perform a CA Rollover within your PKI Realm, and you also wish to update the datasafe (vault) certificate. In order to do the former, you need to issue a new CA Certificate which is capable of issuing certificates for your PKI Realm. Make the CA private key accessible to OpenXPKI, preferably in a way that the system can implicitly reference the private key by its base name and the CA generation (the latter is set during import of the CA signer certificate). How to do that depends on your setup (e. g. key storage in database, in the file system or as a HSM object). Once the CA private key is accessible to the system, import the CA certificate via openxpkiadm as a signer token into the PKI Realm. Once this is done, the system will immediately be able to use the new CA certificate for issuance of new certificate. The old CA certificate remains active and will be used to sign CRLs for revoked certificates for the previous CA generation. Note that these operations can be done without restarting OpenXPKI, during regular runtime. Truly continuous CA operation :-) Importing/activating a new datasafe certifiate is quite similar. Deploy and configure the new datasafe private key at its designated location, import the vault certificate as a datasafe token. If that certificate is issued by a CA in the same PKI Realm, the certificate is already in the database and it is sufficient to just set an alias. The commands for these operations are very similar to the initial setup, please refer to https://openxpki.readthedocs.io/en/latest/quickstart.html Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] [RPC API] Workflow definition for server-side key generation
Hi,
> I'm trying to issue a certificate using the default RPC configuration
> (RequestCertificate method) but a get :
> {
> "result": {
> "id": 3583,
> "proc_state": "finished",
> "state": "FAILURE",
> "data": {
> "transaction_id": "723c94cd1fba71e96d1a5c240fdebf9801f74a1d",
> "error_code": "Invalid Profile"
> },
> "pid": 3481
> }
> }
>
> I'm not setting a certificate profile in the request, I guess it's
> determining the certificate profile from my realm configuration
> (config.d/realm/df/rpc/enroll.yaml)
>
> profile:
> cert_profile: tls_server
> cert_subject_style: enroll
>
> # Mapping of names to OpenXPKI profiles to be used with the
> # Microsoft Certificate Template Name Ext. (1.3.6.1.4.1.311.20.2)
> profile_map:
> pc-client: tls_client
> tls-server: tls_server
> tls-client: tls_client
> #renewal-test: renewal_test
>
> But honestly I don't understand the message "Invalid Profile"
The system is telling you that it does not know which profile to use: the error
happens if the enrollment workflow does not have information about the
certificate profile to use.
Make sure that the profile tls_server (the default profile as per the above
configuration) exists or specify an existing profile in the RPC request.
Note that the value you are sending is mapped via profile_map to the actual
profiles in your PKI Realm.
Cheers
Martin
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] openxpki-client socket permission denied at after upgrade from 3.20 to 3.24
Hi, > Thank you very much for the reply, I was wondering because the config did not > change and everything worked smooth before the upgrade. The semantics I posted have been in place and unchanged for a very long time, and we did not change the relevant code portions recently, so the cause might be something in your runtime environment. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] openxpki-client socket permission denied at after upgrade from 3.20 to 3.24
Hi, > We are using docker containers. At webui.log: > > 2023/05/19 08:34:20 ERR Error creating backend client Error while writing to > socket; __EVAL_ERROR__ => I18N_OPENXPKI_CLIENT_INIT_CONNECTION_FAILED; > __ERROR__ => Permission denied, __SOCKETFILE__ => > /var/openxpki/openxpki.socket [pid=82|sid=9975] > > srwxrwx--- 1 openxpki openxpki 0 May 19 08:35 /var/openxpki/openxpki.socket > > id www-data > uid=33(www-data) gid=33(www-data) groups=33(www-data) > > At working server v.3.20 www-data is in group openxpki: > id www-data > uid=33(www-data) gid=33(www-data) groups=33(www-data),102(openxpki) > > Adding www-data to group openxpki and restarting container fixes the issue. > > Is it a bug or is it configurable somehow? > > P.S. same issue with 3.22 This is expected behavior. You need to properly configure your system with respect to Unix user and group setup as well as setting access permissions properly. The relevant configuration is located in system/server.yaml e. g. ... # Daemon settings user: openxpki group:openxpki socket_file: /var/openxpki/openxpki.socket socket_owner: apache socket_group: apache ... socket_owner and socket_group are optional but can be used to fine tune ownership and permissions. You need to configure your system in a way that the web server can read/write the socket. Other processes and users not related to OpenXPKI should be excluded from accessing the socket. cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] WebUI issue with Remote DB Server of OpenXPKI
Hi, > We deployed the OpenXPKI DB on a separate remote MariaDB server and changed > the details in /etc/openxpki/config.d/system/database.yaml > > The server daemon restarts successfully but the UI doesn't work. It is bound > to the local DB. How can we change it? The Web UI has its own separate configuration file which references the backend storage for session information. In /etc/openxpki/webui/default.conf locate the [session_driver] section and modify its values accordingly. Restart Apache to activate the changes. Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
[OpenXPKI-users] We're Back! Join Us for an Even Better OpenXPKI User Workshop on June 13th 2023 in Frankfurt am Main, Germany
Dear OpenXPKI Users, We are back! After having to cancel our last workshop due to the Covid 19 pandemic, we are thrilled to announce that the OpenXPKI user workshop is finally happening again, and this time, it's going to be even better. We hope this email finds you well, and you are just as excited as we are! White Rabbit Security GmbH is hosting the OpenXPKI user workshop on June 13th, 2023, in Frankfurt am Main, Germany. The workshop is free of charge, but space is limited, and attendance is on a first-come, first-served basis. So, don't wait too long to reserve your spot by sending an email to openx...@whiterabbitsecurity.com. We are also looking for volunteers to present their use cases. How are you using OpenXPKI in your environment, how did you integrate it in your environment and which use cases did you implement? This is an excellent opportunity to showcase your project and share your knowledge with the community. Please note that presentation slots are limited, so apply early by sending an email to openx...@whiterabbitsecurity.com. (Attendees volunteering to present their use case may be preferred.) Here's a preliminary schedule for the day: - 09:00 Doors open, coffee, tea, snacks, and socializing - 10:00 Workshop starts (hosted by White Rabbit Security staff, we outline the latest development and OpenXPKI roadmap) - 12:00 Lunch break and socializing - 13:30 Workshop continues; use case presentations, demos and user talks - 18:00 Workshop closes officially, socializing, small talk, and drinks - 20:00 Attendees who would like to spend the evening with us move to a nearby restaurant More details, exact location and updated agenda to follow soon... We are looking forward to an exciting and productive day, filled with discussions, knowledge sharing, and networking. If you have any questions or concerns, please do not hesitate to contact us at openx...@whiterabbitsecurity.com Best regards, Martin Bartosch White Rabbit Security GmbH -- White Rabbit Security GmbH, Werner-Heisenberg-Straße 8, 85254 Sulzemoos. Contact: +49 8135 314 000-0, off...@whiterabbitsecurity.com Register: HRB 246042, München Director: Martin Bartosch, Scott T. Hardin, Dr. Oliver Welter ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Error when publishing a cert to local disk
Hi, > I am hitting another error when publishing a cert (to a local file). I see > the cert file is written > to local directory, but with a 777 permission which I think is wrong. I observed a similar same problem recently, if the file does not exist, it is created with the system umask. If it exists, it gets properly written with the permissions set in the configuration. It is probably easy to fix on your side: Add the configuration setting mode: "0644" on the same level as "content:" and "file:", this setting defines the octal file mode of the published file. Mind the quote characters and the leading zero. Once this is done, restart the server and repeat the publication process with the target file already in place. Check if the permissions are OK when the file is rewritten, it should be OK then. > Here is the error message right after publishing is finished. > > 2023/02/25 18:19:34 INFO Workflow 2303/certificate_publishing/SUCCESS > executed 'certpublish_publish_profile' (autorun) in state 'PUBLISH' > [pid=75782|user=ra-liu|role=System|sid=HhEJ|wftype=certificate_publishing|wfid=2303] > 2023/02/25 18:19:34 INFO Workflow 2303/certificate_publishing/SUCCESS changed > from state 'PUBLISH' > [pid=75782|user=ra-liu|role=System|sid=HhEJ|wftype=certificate_publishing|wfid=2303] > 2023/02/25 18:19:53 ERROR > I18N_OPENXPKI_TEMPLATE_ERROR_PARSING_TEMPLATE_FOR_PARAM; __ERROR__ => file > error - parse error - input text line 3: unexpected token (END) > [% END %], __TEMPLATE__ => [%I IF meta_email %] > I18N_OPENXPKI_UI_WORKFLOW_FIELD_META_EMAIL_LABEL: [% FOREACH mail = > meta_email %] > mailto:[% mail %]">[% mail %], > [% END %][% END %] > [pid=75725|sid=Av82] > > I am not sure if these are related to the publishing. The error message indicates that you have an error in your Template code. > __TEMPLATE__ => [%I IF meta_email % The I following the percent sign looks fishy :) Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Questions about publishing CRL and use san_email
Hi, > My further test shows that CDP works correctly if the director is owned by > openxpki user. > Previous it was owned by apache user/group with group writeable permission. > openxpki > user is a member of apache group. This did not work. I am not sure why, > likely because > the perl module does not honor the supplementary group permission. This is expected behaviour: the group assignments in /etc/group are ignored by the OpenXPKI server process. The reason is that the Net::Server base class we use in OpenXPKI requires explicit configuration of the Unix user and group to assume when daemonizing the server on startup, and it can also only assume one single group membership. See user and group in https://metacpan.org/dist/Net-Server/view/lib/Net/Server.pod#user So you should make sure that you plan a proper user/group/permission scheme for your runtime environment and allow write access for the configured Daemon user or group. Hope this helps, cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] clca vs openxpki
Hi, > Does software > https://github.com/openxpki/clca > depend from software > https://github.com/openxpki/openxpki > or does it conflict with the latter, if installed on the same host? This is not a problem, both projects will work properly on the same system. Cheers, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Duplicate Key Error (Request) while creating cert with CSR
Hi, > I am generating a cert from OpenXPKI UI with CSR but i get "Duplicate Key > Error (Request)". Kindly guide me. You uploaded a CSR which uses a key which has already been seen by your OpenXPKI instance, hence "Duplicate Key Error". You need to generate a new private key and a new certificate request from this. Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] OpenXPKI SCEP enrollment for 2 different profiles
Hi, > Is it possible to configure OpenXPKI SCEP enrollment for 2 different profiles > e.g. TLS server and TLS client? Sure it is. See the recent posts related to EST. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] EST using different profiles
Hi, > I have only one CA, but is it possible to configure EST with 2 different > profiles? > I would like to setup one for User certs. and one for TLS server certs. Within any OpenXPKI PKI Realm you can configure an arbitrary number of EST, SCEP and RPC endpoints. Each endpoint has its own distinct configuration, making it possible to provide endpoints, e. g. specific for a device group. (In terms of long term manageability this is an important feature, making it possible to modify the enrollment policy e. g. only for your printers while leaving the enrollment policy for phones unchanged.) Each endpoint has a default certificate profile configuration which is selected if no other supported profile is requested by the client (and accepted by the endpoint). The client may override the configured default profile by including the Microsoft specific extension 1.3.6.1.4.1.311.20.2 (szOID_ENROLL_CERTTYPE_EXTENSION, http://oid-info.com/cgi-bin/display?oid=1.3.6.1.4.1.311.20.2=display) in the submitted CSR. If the profile requested by the client is contained in the profile mapping of the endpoint configuration, the mapped profile is used for the incoming certificate request, otherwise the default is used. HTH Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Renew certificate expired
Hi, > I have very little experience, and my scant use of english and documentation, > I can't figure out how to renew an expired certificate, could you tell me how > to renew the certificate, please. The most straightforward way is to generate a new private key, a certificate request from the key, raise a request with the PKI, issue the certificate and deploy the certificate on the end entity. If you want to automate things, you could consider using SCEP or EST for automatic renewal of the certificate (however, this needs to be done while the cert is still valid). Cheers, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Default value's in profile templates
Hi, > ***SNIP*** > I was adding a new certificate profile last week and had to add the new field > template. > For that new use case, the value for the field would always be the same. So > I'd like to have this pre-filled when reaching the workflow step but still > editable, if it needs to be changed. > In the sample no "default" value is mentioned, but I'd like to have that > available. > Is there an option available? > ***SNAP*** > > I have the same problem and I am looking for a solution for it. Can anyone > help me? Default field values in templates can be set via "preset". There are quite some examples using such a preset in the profile/template/ directory. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] SmartCard-HSM or Nitrokey integration
Hi, > As I know, openxpki supports PKCS#11 interface via OpenSC > I'm making a Lab to implement a CA with signer key protected inside HSMs such > as SmartCard-HSM or Nitrokey, in documentation there is an example for > YubicoHSM but I don't get the full idea and the required steps, > I tried to adapt the YubicoHSM example with SmartCard-HSM but no luck till > now, there is no errors in log, but still no signer, > Is it enough to set the right token in crypto.yaml file with the matching > secret? > Is there anything to put in the database or some command to execute? > How to select which signer key within the token to use? What Oliver said, and some additional background informatino: OpenXPKI natively supports PKCS#11 via OpenSSL. I suggest to start outside OpenXPKI, set up the HSM so you can use it from the command line via OpenSSL. Figure out how tokens and keys are properly referenced and which settings are required to make things work with the HSM. This is dependent on the hardware's PKCS#11 library. While you are at it, create a CSR for your CA signing key with your HSM protected key via OpenSSL. Issue the CA certificate, import it as a CA token in the OpenXPKI realm and make sure that the configuration references the correct and matching private key protected by the HSM. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Disabling PKCS10 signature verification
Hi Mukilan, > Does it mean that we can't ignore signature verification for CSR? I will > explain the use case. We would like to modify the SubjectDN/SAN as part of > our own policy while internal clients (devices, computers and etc) are > raising certificate requests. The internal clients will send the CSR to a > proxy, then proxy will contact on behalf of client to send CSR and receive > certificate. The proxy will do all the policy implementation related to > Subject and SAN. > Since the Subject DN/SAN is modified in proxy, we would like to instruct the > OpenXPKI to ignore signature validation for CSR. Is there any > way/configuration parameter to instruct the OpenXPKI to ignore the signature > validation for CSR. Well, this is not how it's supposed to work. ;) I honestly cannot imagine a use case in which it would be necessary to modify the CSR itself in order to enforce a naming policy (and I have seen a *lot* of really strange requirements). OpenXPKI itself provides sufficient means to selectively process data provided in the CSR to form the desired DN/SANs. Get rid of that proxy and configure your policy correctly. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Microsoft Active Directory with OpenXPKI
> I've an Active Directory for my domain users. Can I fetch users list from AD > and request certificates on behalf of Active Directory users from OpenXPKI > web interface? You can do a lot of things with OpenXPKI, and the answer is probably yes. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Microsoft Active Directory with OpenXPKI
> Does OpenXPKI support certificate generation from Microsoft Active Directory? This question does not make any sense. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] key distribution
Hi, > Does OpenXPKI have any feature to distribute public keys over all servers or > not? It eludes me why this might be necessary. In addition, OpenXPKI has no way of knowing what "all servers" are. However, OpenXPKI provides a configurable publishing operation which is executed on every certificate issuance. Certificates can be published to any number of configurable publication targets, including a local file, LDAP add/modify, scp and more. Publication targets can be defined on a per profile basis. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Request for help to configure CRL (certificate revocation list) for EST protocol in openxpki 3.x
Hi, > I want to configure CRL (certificate revocation list) for EST protocol in > openxpki 3.x server. I did it for SCEP protocol in openxpki 2.x. Can you > please help me with the required steps for EST (e.g. Generating CRL > information, Configuring CRL accessibility etc.) > > For your reference, I’m attaching the used steps for SCEP. I am afraid I do not understand the question/problem. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] How to Configure YubiHSM in CLCA
Hi, > The CLCA documentation https://github.com/openxpki/clca specifies to use the > nCipher & Gemalto HSM as follows. > > # Define crypto engine to use. Supported values are > # openssl - OpenSSL software only (private keys stored on disk) > # chil - nCipher hardware > # gem - Gemalto Safenet Luna SA hardware > > How can we configure the CLCA to use YubiHSM? - determine how the YubiHSM can be used with OpenSSL - identify the correct engine to use (likely pkcs11 with the YubiHSM2) - identify the correct key reference to use via PKCS#11 Craft a proper openssl.cnf file for your setup. Set ENGINE to the correct engine Set ROOTKEYNAME to the correct key identifier > Furthermore, there is no detailed documentation is available for the > configuration of CLCA from scratch. Kindly share, please. The Open Source version of clca is documented in a way that allows skilled IT Security professionals to make proper use of the tool in the current form. Should you desire a more polished product, detailed user documentation or should you need assistance in setting up a proper offline CA environment with clca I suggest to get in touch with White Rabbit Security for the clca Enterprise Edition. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Bridge CA in OpenXPKI?
> That sounds great. How we can setup BridgeCA in OpenXPKI? You analyze your requirements, define a resulting PKI architecture and implement it properly. ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Store OpenXPKI CA Key in AWS CloudHSM
> Is it possible to store the CA key in OpenXPKI on AWS CloudHSM? > Yes. ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Bridge CA in OpenXPKI?
> Is it possible to create a Bridge CA in OpenXPKI? Yes. ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Cannot autorenew scep requested certificate
Hi, > You're right, certmonger seems to keep the same private key for renewal. > So certmonger may not be usefull as I read in the getcert man : > > -r automatically renews the certificate when its expiration date is close if > the key pair already exists. This option is used by default. > > Certmonger renewal need to keep the same private key : "if the key pair > already exists". Am I wrong ? You are right. In my opinion this is not very useful. There is a lot of poorly implemented crypto out there, and this includes the "big players". Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Cannot autorenew scep requested certificate
Hi, > I am stuck in testing autorenew of scep requested certificates. > > This is my initial enrollment with certmonger : > ``` > getcert request -c openxpki -f $certfolder/nginx2.crt -k > $keyfolder/nginx2.key -g 4096 -r -N cn=nginx2.domain.lan -v -w -L > SecretChallenge > ``` > > On client side, Certmonger is aware that the certificate will not be valid > after 2022-02-14 15:03:47. OpenXPKI supports SCEP enrollment as an initial enrollment (new private key, unauthenticated/self-signed request) and as a renewal request (new private key, request signed with existing/old certificate and key). Renewal requests only work as long as the existing certificate is still valid. With the default configuration/workflows it is not possible to renew an expired certificate. This makes sense, a certificate should be renewed before it expires. > On OpenXPKI side. I understand that the SCEP server find the appropriate > initial workflow (9983). But is it delevering a new certificate by telling > "Delivered certificate via SCEP" ? Am I supposed to see a new workflow ? Works as designed, this indicates that the client sends an initial enrollment request, not a renewal request. If the original private key is used to request the certificate, the existing certificate will be delivered. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Support of CMP and 3GPP in OpenXPKI???
Hi, > Does OpenXPKI support CMP and 3GPP standards? No, it does not. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Problems with setup (democa)
Hi, >>> I can find the certificates in the sql dump (BEGIN CERTIFICATE) but I >>> can't find any string with 'BEGIN ENCRYPTED PRIVATE KEY'. Where is the >>> private key located? > >> The keys are wrapped into a PKCS7 containe - look for something where >> the namespace column has a value of sys.crypto.keys > > what's the preferred way, store in database or put a keyfile with permission > 0400/user openxpki on hdd ? It's your decision. Back in the day when I designed this initially I deliberately chose not to have any key material in the database. (That was at a time when the datapool did not exist yet, though.) Over the time we found that many users seem to prefer their software keys in the database, as this makes cluster setups easier to manage, so we implemented this. Both has its advantages and disadvantages, and we leave the decision for/against storing keys in the datapool to the skilled PKI architects who use our PKI software. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Fwd: Openxpki workflow could not find token alias
Hi, > I do have a question about the maximum validity. > As I understand, the CA validity has to be longer or the same as the > configured validity in the used profile (which currently is +01, which is 1 > year as i understand) > Now my CAs are valid for 1 year, and have a bit of overlap. > > Issuing certificates of this Realm > Subject not before not after > CN=Factory CA,OU=Hyva,O=Sioux,ST=Noord Brabant,C=NL 2022-11-14 00:00:00 UTC > 2023-11-14 00:00:00 UTC > CN=Factory CA,OU=Hyva,O=Sioux,ST=Noord Brabant,C=NL 2021-12-09 09:23:55 UTC > 2022-12-09 09:23:55 UTC > > But I am still getting the same error. > Does this mean that the overlap of certificate validity has to be at least > the duration of the issued certificate? > (so that there is always 1 CA that is valid for the full duration of the > requested certificate) > > Sorry if this more a generic CA related question instead of an openxpki one. We are leaving OpenXPKI grounds here... As mentioned in the previous mail you need to design your PKI properly, in this particular case with regard to the CA validities. This means that you need to align the CA validity with the maximum required end entity validity. Make sure to provide CA certificates which have a sensible/usable usage period in which they are fully capable of issuing the maximum required subordinate certificate validity. Also make sure to design (and test) the CA rollover process properly. When I design a PKI I typically recommend CA Validity := 2 * (maximum required subordinate validity) + some slack value Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Openxpki workflow could not find token alias
Hi, > I run into the following error during trying to (automatically) sign a CSR > for the factory_ca realm > > 2021/12/09 10:42:36 255 start cert issue for serial 255, workflow 255 > 2021/12/09 10:42:36 255 NICE backend error: Could not find token alias by > group; __group__ => ca-signer, __noafter__ => 1670578956, __notbefore__ => > 1639042956, __pki_realm__ => factory_ca > > I checked the ca-signer inside openxpki client and it is Online under name > ca-signer-1 > Which you can also see in the listing of the realm > > ca-signer (certsign): > Alias : ca-signer-1 > Identifier: m8UxpPiH9ux60PrL3_c0NDkiRDg > NotBefore : 2021-12-09 09:23:55 > NotAfter : 2022-12-09 09:23:55 > > As far As I found in documentation. You dont need to update the -1 -2 etc on > rollover. > > What am i missing here? You are trying to issue a certificate which is valid until Fri, 09 Dec 2022 09:42:36 GMT, but your Issuing CA is only valid until 2022-12-09 09:23:55. Hence your CA system can no find a suitable CA certificate which can issue the requested certificate validity. When designing your PKI you should align your CA validities properly with the maximum required end entity validity (which does not seem to be the case here). And you should also plan for the regular CA rollovers and prepare your system by importing the new CA certificate and associating it with the private key. If the regular CA rollover is executed properly your PKI will work indefinitely. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Extensions: key usage: how to have only "key usage" asked by the CSR
Hi, > I'm guessing this has been already asked, I searched the archives to no avail. No, as far as I am concerned I have never seen this requirement before. > I generate my CSR with key usage information “DigitalSignature” and “Key > encipherment” (using OpenSSL API). > But when I get my enrolled certificate I have a new key usage “key agreement”. > I saw is configurable in tls_server.yaml, but is it possible to have > automatically and only the key usage asked by the CSR? This is a feature, not a deficiency. By design OpenXPKI ignores most data supplied by the client in the CSR (with certain exceptions, such as subject, SANs and of course the public key) and strictly enforces the defined certificate issuance policy, in this case the profile properties when issuing the certificate. If certificates with the DigitalSignature and KeyEncipherment key usage bits should be generated, the CA designer needs to define a profile which explicitly sets these key usage bits and have the client reference this profile. If a client should be able to request different types of certificates the client should either choose the correct profile (when using the manual request workflow) or provide profile information with the request when using automated enrollment interfaces. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Install OpenXPKI on Debian 11.0.0
> Can someone on the list update me on when pre-compiled packages for Debian 11 > Bullseye will be available? > > Regards > Scotty > > On Wednesday, 20 October 2021, 02:52:29 pm GMT+5, Martin Bartosch > wrote: > > > Ceterum censeo Carthaginem esse delendam. I may have raised false hopes, as in the end Carthage was indeed destroyed. My apologies. > > > > Am 20.10.2021 um 06:54 schrieb Scott Thomas via OpenXPKI-users > > : > > > > Hi, > > > > Any update of OpenXPKI pre-compiled packages on Debian 11.0??? > > > > Cheers > > Scotty > > > > On Monday, 4 October 2021, 02:16:17 pm GMT+5, Scott Thomas via > > OpenXPKI-users wrote: > > > > > > Bonjour, > > > > When will be OpenXPKI pre-compiled packages available on Debian 11.0? > > > > Regards > > Scotty ... ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Install OpenXPKI on Debian 11.0.0
Ceterum censeo Carthaginem esse delendam. > Am 20.10.2021 um 06:54 schrieb Scott Thomas via OpenXPKI-users > : > > Hi, > > Any update of OpenXPKI pre-compiled packages on Debian 11.0??? > > Cheers > Scotty > > On Monday, 4 October 2021, 02:16:17 pm GMT+5, Scott Thomas via OpenXPKI-users > wrote: > > > Bonjour, > > When will be OpenXPKI pre-compiled packages available on Debian 11.0? > > Regards > Scotty > > On Thursday, 16 September 2021, 09:09:30 am GMT+5, Scott Thomas via > OpenXPKI-users wrote: > > > Till when the pre-compiled packages for Debian 11 Bullseye will be available? > I am waiting anxiously. > > Regards > Scotty > > On Thursday, 9 September 2021, 03:44:13 pm GMT+5, hvli01538 > wrote: > > > Hi Scotty, > > Looking at https://packages.openxpki.org/v3/debian/dists/ I would say > "not yet". There will be a directory "bullseye" once support for the new > release is ready. Until then it may or may not work with the currently > available packages. > > Regards, > Andreas > > > On 09/09/2021 11:36, Scott Thomas via OpenXPKI-users wrote: > > Bonjour, > > > > Is it possible to install OpenXPKI latest version on Debian latest > > version 11.0.0 using precompiled packages? > > > > Regards > > Scotty > > > > > > > > > ___ > > 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 > > ___ > 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 > ___ > 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
Re: [OpenXPKI-users] How do I retrieve a Certificates key via RPC-call to http://localhost:8080/rpc/enroll/SearchCertificate
Hi,
> Meanwhile I found out, that sending REST-Requests with the right header works
> fine for me:
>
> curl -s -X POST http://localhost:8080/rpc/enroll/SearchCertificate -H
> 'Content-Type: application/json' -d '{"common_name":"Rob Roberts"}' | python
> -m json.tool
I don't really know your use case but I assume you would be much better served
with properly adapting the Enrollment Workflow to your needs.
> PS: To be honest: I am struggeling hard with openXPKI server’s
> documentation – the software itself seems to be quite promising, but
> documentation is hard to understand and quite limited (at least from my point
> of view).
The publicly available documentation of the OpenXPKI Community Edition provides
an overview and a quickstart guide on the software, covering a simple use case
of OpenXPKI to get things up and running.
From my observation most OpenXPKI CE users seem to be able to get their system
up and running with this documentation, and with help on this mailing list it
looks like we were also able to support users with some more advanced questions.
OpenXPKI is a very powerful and complex PKI software product - after all it is
enterprise grade software. So due to the amount of features and functionality
the CE documentation naturally only covers a tiny fraction of the available
feature set.
However, we will gladly accept user contributions to improve the quality of the
OpenXPKI CE documentation.
Beyond the quickstart guide there is also a significant amount of class
documentation within the OpenSource code base itself, as most internals are
properly documented within the class structure of OpenXPKI. A developer or
designer with more specific goals will have to learn how OpenXPKI works and dig
into the details.
Becoming familiar with the features of OpenXPKI takes time, we have found that
even with extensive mentoring from our OpenXPKI core team a new developer or
integrator will take a few months to become productive with the system.
That said, I would like to mention that the Enterprise Edition of OpenXPKI is
available as a commercial product from our company White Rabbit Security GmbH
which comes with extensive (400+ pages) of configuration, integration,
operation and development documentation covering all aspects of the system.
Cheers,
Martin
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] How enable Intermediate certificate CRL.
Hi, > We are facing the issue while validating the certificate using ocsp. We did a > bit of R from our side and we found the following issue when we tried to > use the following command. > screenshot attached. The OpenXPKI OpenSource edition does not include an OCSP server, this is a component of the OpenXPKI Enterprise Edition. I suggest you raise a support ticket with the vendor of your OCSP responder. Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] How enable Intermediate certificate CRL.
> We are able to enable .p12 certificate CRL for certificate revocation. But we > need to enable CRL for intermediate certificates i.e our requirement. > Screenshots are attached along with mail for more understanding. If you are asking where you can configure the CDP in the certificate profile default: https://github.com/openxpki/openxpki-config/blob/community/config.d/realm.tpl/profile/default.yaml#L93 Regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] How enable Intermediate certificate CRL.
> Please guide us to enable Intermediate certificate CRL in the openxpki > environment.We are using openxpki version 3.12 in our environment. I don't understand this question. Regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Openxpki login with external ldap users
> We have used Openxpki version 3.12 in our environment. Our requirement is > that we want to authenticate openxpki with external ldap login from openxpki > UI. Please help us, how can we integrate external ldap users with openxpki, > so that we can login from openxpki web UI using external ldap users. We don't > want anonymous user login from openxpki web UI. > Please read the documentation and search the mailing list archive. This question has been covered there only recently. Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] 4 eyes to approve/issue certificate
Hi, > I mange to enforce policy of 2 approvals required by RA Operators (4 eyes) in > order to issue a certificate using WEBUI interface > > Is it possible! Any advice! (Almost) everything is possible with OpenXPKI ;-) For the automatic enrollment interfaces the approval policy is located in the PKI Realm endpoint configuration (e. g. scep/*.yaml or rpc/*.yaml). There you can configure the number of "approval points" which need to be present before a request is approved and the certificate is issued. The setting "approval_points" denotes the number of approvals required to proceed. Note that an approval point can be obtained both by an automatic check or by a manual approval. For manual enrollment (via the UI) a different workflow is used, hence the configuration is at a different place. If you wish to enforce the independent approval of multiple roles (e. g. two RA Operators must approve the request) this can be done by modifying the workflow configuration. Try this: --- a/config.d/realm.tpl/workflow/def/certificate_signing_request_v2.yaml +++ b/config.d/realm.tpl/workflow/def/certificate_signing_request_v2.yaml @@ -693,7 +693,9 @@ condition: is_approved: class: OpenXPKI::Server::Workflow::Condition::Approved param: -role: RA Operator +role: +- RA Operator +- RA Operator can_use_server_key: class: OpenXPKI::Server::Workflow::Condition::KeyGenerationMode I have not checked it myself, but this should do the trick. If it does not work, try duplicating the "role: RA Operator" line instead, but I think I got it right. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Upgrade from 2.x to 3.12
Hi,
> OK, everything working now.
>
> The name of the realm in the database deviated from the name in the
> filesystem. That's why I didn't see existing certificates.
>
> Thus the SQLs used for upgrading the schema seem to be correct. Only
> migrating the Sequences was needed an additional "+1" for hitting the correct
> number like so:
>
> % sudo mysql openxpki -sNe "show tables" |grep "^seq_" |sudo xargs -n1 -I{}
> mysql openxpki -sNe 'select concat("DROP TABLE {}; CREATE SEQUENCE {} START
> WITH ", ifnull(max(seq_number),0)+1, " INCREMENT BY 1 MINVALUE 0 NO MAXVALUE
> CACHE 1;") from {}' >migration_ddls_part2.sql
>
> Would it make sense to detail the migration path a little more in
> https://raw.githubusercontent.com/openxpki/openxpki-config/community/UPGRADEv3.md?
>
> I could open a Pull Request, if that makes sense.
Glad to hear you got it working. PRs to improve the documentation are always
appreciated.
Best regards,
Martin
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] directory /etc/openxpki/contrib/local missing
Hi, > While working through the steps for a productive setup on Debian I came > across the following instruction in > https://github.com/openxpki/openxpki-config/tree/community#credentials--local-users > >> The files are already linked into the configuration layer and must >> be created before the system can be used. Templates for those files >> are provided in contrib/local, copy the directory cp -a >> /etc/openxpki/contrib/local /etc/openxpki and adjust the files as needed. > > However, the directory "/etc/openxpki/contrib/local" is missing in both > the package deployed config and the config from GitHub. > > Is this instruction a leftover of an abandoned approach or is the > directory just missing because of a build error? > If the latter is true, where can I get the directory from? We use the local directory in our deployments to store files which may contain sensitive information such as the database or LDAP server password. It also may contain the CA private keys if you do not use a HSM and choose not to store the CA key in the database. These files are not checked into a revision control system for obvious reason, hence they are not in the upstream config repository. Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Need help in crl
Hi, > We are using openxpki version 3.12 in our environment. We are able to add > revoke certificates in .crl manually using openxpki raop. But we want to run > the revoke command using cron jobs per day. Please give us the command which > runs the backend for revocation & add .crl list. please see https://sourceforge.net/p/openxpki/mailman/openxpki-users/thread/550943e1-8490-598c-b4db-2a86080fc02f%40oliwel.de/#msg37285829 Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Authenticate RAOP from Active Directory
Hi, > Can we modify openxpki raop role to get authenticated from a Microsoft Active > Directory account? If not then what other aternative possible instead of > storing the hashes in yaml files??? Yes. https://openxpki.readthedocs.io/en/latest/reference/configuration/realm.html#authentication contains an example how to authenticate against LDAP/AD. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Multiple DNS entries in subject alternative name
Hi, > How can we customise the web server profile in OpenXPKI to include multiple > DNS entries in subject alternative name? An arbitrary number of SANs is already supported in the upstream configuration sample of the TLS Server profile (and has been there since about 2010 or so). Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Workflow Pause
Hi, > Thank you very much, how always to you Oliver! > > The only error that I detect is the openxpki.log and it is the following: > 2021/08/05 11:02:13 ERROR Could not find token alias by group; __group__ => > ca-signer, __noafter__ => 2101557733, __notbefore__ => 1628172133, > __pki_realm__ => XX > [pid=22660|sid=PLa1|wftype=certificate_signing_request_v2|wfid=327935] > 2021/08/05 11:02:13 ERROR Caught exception from action: [Generic exception]; > reset workflow to old state 'APPROVED_GLOBAL_PERSIST_CSR_0' > [pid=22660|sid=PLa1|wftype=certificate_signing_request_v2|wfid=327935] > > what should I do? Looks very much like your system cannot find a suitable Issuing CA because the remaining validity of the current Issuing CA is not capable of issuing the requested end entity certificate validity. You should have prepared for this situation by issuing a rollover CA Certificate and configuring it in your system. This operation can be done without downtime, and the system will seamlessly roll over to the new Issuing CA if this is done properly. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] How to start OpenXPKI with alternative locale?
Hi, > Martin, did you have a fight or some conflict with this Petr Grigoriev > ? In the section ru_RU, such nonsense is written ... Not as far as I can remember. We had a really nice working relationship with the team at the time. I am sorry to hear that the Russian translation is botched. At that time there were no good language translation tools available, nowadays we at least perform some sanity checks on submitted translation work. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] How to start OpenXPKI with alternative locale?
Hi, > I have set ru_RU-UTF8 and restart apache & system with Russian locale but > never see any changes at web interface > PS Debian 10.10 and OpenXPKI. Successfully started with en locale The Russian translation files do exist, but the content is largely non-existent (almost all translations in the .po file are marked as fuzzy which means they are not used). If you need a Russian interface you will have to create the translation files yourself, compile the .mo file, deploy it and restart Apache as well as OpenXPKI. We would appreciate a pull request with the translation of course. Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] How to start OpenXPKI with alternative locale?
Hi, > I have set ru_RU-UTF8 and restart apache & system with Russian locale but > never see any changes at web interface > PS Debian 10.10 and OpenXPKI. Successfully started with en locale Please note that the Russian localization is very old and currently unmaintained (we do not speak that language, so we have to rely on user contributions). It is very likely that a large number of translation tags currently used by the system are not contained in the old Russian .po file, resulting in the default translation. Currently the most up-to-date localizations are English and German. Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] unique certificate subject across all realms
Hi, > Is it possible to check if the certificate subject is unique across all > realms on the openxpki server? I am using openxpki community edition. OpenXPKI is a workflow based system, so literally almost any conceivable business logic can be implemented. We distribute a set of default workflows which implement some common and sensible assumptions. One of the assumptions is that PKI Realms are logically separate name spaces, making it possible to any number of distinct and independent CAs on the same OpenXPKI instance. The default system hence only considers uniqueness of subjects within the same PKI Realm, not across other realms. I am not sure and have not tested this, but by looking at the code and configuration you could try the following: In the workflow/def/certificate_signing_request_v2.yaml of your desired realm change the subject policy test from check_policy_subject_duplicate: class: OpenXPKI::Server::Workflow::Activity::CSR::CheckPolicySubjectDuplicate param: allow_renewal_period: "+0003" to check_policy_subject_duplicate: class: OpenXPKI::Server::Workflow::Activity::CSR::CheckPolicySubjectDuplicate param: any_realm: 1 allow_renewal_period: "+0003" This should consider the subject test across all realms. This is untested. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Use SHA256 OR SHA512 for RAOP
> Thanks for the support, I have at least switched from SHA1 to ARGON2. > > I am using OpenXPKI Version (core): 3.10.2 but the options of SHA256 and > SHA512 are not available to me. I have double checked it again. Please upgrade to 3.12.0. The feature you require was introduced in version v3.11.2. Regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Use SHA256 OR SHA512 for RAOP
> The SSHA of the raop1 is placed in
> /etc/openxpki/config.d/realm.tpl/auth/handler.yaml as
>
> raop1: "{ssha}zsmRmCaV2+Mg2t49v5hk3znKOL1VbnRz"
>
> the openxpkiadm hashpwd of OpenXPKI gives the following output
>
> Your hashed password is:
> $argon2id$v=19$m=32768,t=3,p=1$OTF5RTA5ZEt5cHM5Qmord1hRSktoQT09$fP5TeBuDgqimXDoCXH+q2g
>
> How the argon2 will be used in handler.yaml file for raop argon2 password??
That would be
...
Operator Password:
type: Password
# The passwords can be generated with "openxpkiadm hashpwd"
# or with "openssl passwd -5"
# The password below is "openxpki" for all three users
role: RA Operator
user:
raop:
"$argon2id$v=19$m=32768,t=3,p=1$OTF5RTA5ZEt5cHM5Qmord1hRSktoQT09$fP5TeBuDgqimXDoCXH+q2g"
...
> Furthermore what is the command switch to use SHA512, i am trying the
> following one but it is not working
>
> openxpkiadm hashpwd -s sha512
> Unsupported scheme - supported values: sha|ssha|md5|smd5|crypt|argon2
Works for me:
# openxpkiadm hashpwd
Please type your password, end with return:
Please re-type your password:
Your hashed password is:
{ssha256}Fx1qiNnzVWvgG1dwyk973l03lcHNhP7Ffi5Rgjmz2w8rT0Q2Y2lhUUxsL1hqVEtwSUpqektRPT0=
# openxpkiadm hashpwd -s sha256
Please type your password, end with return:
Please re-type your password:
Your hashed password is:
{sha256}iNQmb9TmM40TuEX88olXnSCciXgjuSF9o+Fhk28DFYk
# openxpkiadm hashpwd -s sha512
Please type your password, end with return:
Please re-type your password:
Your hashed password is:
{sha512}2AIvIGCtbv0perc9zFNVybIUBUsNF3ahNqZp0mp9OxT3OqDQ6/8Z7jMzaPAWS2QZqW2knj5IF1Pn6Wtxa9zLbw
Regards
Martin
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unique Certificate Subject in OpenXPKI
> I had mailed for unique certificate subject in OpenXPKI, so that I can't > create a duplicate certificate for same user subject. The communication on > the thread > > Re: [OpenXPKI-users] Support of Unique certificate subject in OpenXPKI > Re: [OpenXPKI-users] Support of Unique certificate subject in OpenXPKI > > > > was inconclusive. An urgent response will be highly appreciated as the issue > is still pending. This is quite an interesting statement, I must say. ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Use SHA256 OR SHA512 for RAOP
> OpenXPKI uses SSHA salted Sha 1 for raop password authentication via > openxpkiadm hashpwd. How can we configure to use a higher version of SHA such > as SHA256 OR SHA512? The OpenXPKI password authentication handler supports salted md5, sha1, sha224, sha256, sha384 and sha512, crypt and argon2. A hashed argon2 password can be generated e. g. via openxpkiadm hashpwd -s argon2 Most installations I know of delegate user authentication and authorization to a suitable authentication backend, e. g. an LDAP directory. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] System Status error
Hi Gabriel, > I have a problem with the status of the system, in the OpenXPKI home, the > status of the Token Vault does not appear, it does not show data, I attach a > link with Image > > https://drive.google.com/file/d/188bs3cDkUgZqI2QdjHjVHfD4-lttSraD/view?usp=sharing Just a side note: looking at that screenshot in your post it looks like you did a Spanish translation of the OpenXPKI system. If you are willing to share your translation efforts we would very much welcome it as a contribution to the OpenXPKI OpenSource project. Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment"
Hi, > Thanks you Oliver, I succeed with SSCEP to sign my client with the PKI#2 > previously signed by PKI#1 (This post helped me > too:https://sourceforge.net/p/openxpki/mailman/message/36904820/) > > But I have still two questions: > • The quick one; in case where I have 2 signers (e.g.: ca-signer-1 and > ca-signer-2) is it possible to set/configure that only ca-signer 1 signs a > certificate request? (SCEP enrollment) – because currently the last signer I > add, the last signer who signs the request. See https://sourceforge.net/p/openxpki/mailman/openxpki-users/?viewmonth=202105=18=flat for a very similar question and answer. > • The second question arrived because I trying to do the on-behalf – > already made with SSCEP – now with Cryptlib. > The PKI#1 (openxpki with workaround in the workflow) signs my client (START > INITIAL is triggered) – this part is OK. Then the PKI#2 trying to sign my > client (I trying to reach START ON-BEHALF) but I failing before that, I get > lot of errors from LibSCEP: > > I don’t know which ASN1 field(s) have a problem, is it possible to know that? Sorry, I currently don't have the time for ASN.1 diving... Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
