You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(61) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(8) |
Feb
(36) |
Mar
(4) |
Apr
(34) |
May
(1) |
Jun
(31) |
Jul
(25) |
Aug
(2) |
Sep
(6) |
Oct
(15) |
Nov
(1) |
Dec
|
| 2008 |
Jan
(21) |
Feb
(6) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(18) |
Aug
(1) |
Sep
(13) |
Oct
(9) |
Nov
|
Dec
(3) |
| 2009 |
Jan
(31) |
Feb
(19) |
Mar
(1) |
Apr
(3) |
May
(26) |
Jun
(1) |
Jul
(6) |
Aug
(15) |
Sep
(2) |
Oct
(8) |
Nov
(18) |
Dec
(11) |
| 2010 |
Jan
(8) |
Feb
(3) |
Mar
(13) |
Apr
(3) |
May
(22) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(4) |
Oct
|
Nov
(11) |
Dec
(2) |
| 2011 |
Jan
|
Feb
(12) |
Mar
(11) |
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(28) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(5) |
Jun
(16) |
Jul
(1) |
Aug
|
Sep
(33) |
Oct
(6) |
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(12) |
May
(1) |
Jun
|
Jul
(21) |
Aug
|
Sep
(19) |
Oct
(2) |
Nov
(35) |
Dec
(11) |
| 2016 |
Jan
(6) |
Feb
|
Mar
(6) |
Apr
|
May
(16) |
Jun
(7) |
Jul
(8) |
Aug
(10) |
Sep
(13) |
Oct
(13) |
Nov
(17) |
Dec
(24) |
| 2017 |
Jan
(38) |
Feb
(36) |
Mar
(7) |
Apr
(4) |
May
(29) |
Jun
(14) |
Jul
(5) |
Aug
(3) |
Sep
(9) |
Oct
(18) |
Nov
(20) |
Dec
(30) |
| 2018 |
Jan
(11) |
Feb
(14) |
Mar
(3) |
Apr
(7) |
May
(3) |
Jun
(11) |
Jul
(19) |
Aug
(11) |
Sep
(30) |
Oct
(47) |
Nov
(19) |
Dec
(18) |
| 2019 |
Jan
(14) |
Feb
(24) |
Mar
(31) |
Apr
(20) |
May
(35) |
Jun
(18) |
Jul
(10) |
Aug
(35) |
Sep
(11) |
Oct
(4) |
Nov
(7) |
Dec
(35) |
| 2020 |
Jan
(20) |
Feb
(15) |
Mar
(27) |
Apr
(45) |
May
(15) |
Jun
(25) |
Jul
(17) |
Aug
(67) |
Sep
(23) |
Oct
(44) |
Nov
(75) |
Dec
(30) |
| 2021 |
Jan
(3) |
Feb
(18) |
Mar
(18) |
Apr
(46) |
May
(54) |
Jun
(73) |
Jul
(21) |
Aug
(103) |
Sep
(54) |
Oct
(38) |
Nov
(38) |
Dec
(18) |
| 2022 |
Jan
(16) |
Feb
(21) |
Mar
(24) |
Apr
(24) |
May
(17) |
Jun
(20) |
Jul
(13) |
Aug
(18) |
Sep
(17) |
Oct
(8) |
Nov
(24) |
Dec
(11) |
| 2023 |
Jan
(34) |
Feb
(40) |
Mar
(14) |
Apr
(11) |
May
(23) |
Jun
(30) |
Jul
(26) |
Aug
(61) |
Sep
(43) |
Oct
(9) |
Nov
(34) |
Dec
(27) |
| 2024 |
Jan
(45) |
Feb
(63) |
Mar
(62) |
Apr
(61) |
May
(26) |
Jun
(41) |
Jul
(35) |
Aug
(86) |
Sep
(33) |
Oct
(28) |
Nov
(20) |
Dec
(7) |
| 2025 |
Jan
(12) |
Feb
(30) |
Mar
(19) |
Apr
(20) |
May
(20) |
Jun
(6) |
Jul
(26) |
Aug
(15) |
Sep
(15) |
Oct
(9) |
Nov
(12) |
Dec
(8) |
| 2026 |
Jan
(2) |
Feb
(7) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Martin B. <vc...@cy...> - 2026-03-04 14:43:56
|
Hi, > Is it safe to clear the application log and the workflow history manually from the database? You can (and should) use regular logrotation on the log files, so they do not grow independently. Perform log file pruning to your liking and retain the desired backlog. If you really wish to delete PKI workflow data you can do the following. Test this first thoroughly on a dev system. It should be safe to delete from the workflow_history table without any repercussions. Deleting workflow context entries from a workflow instance should be possible if the workflow will not be used again (is in a final state). If you delete workflow context entries of an Deleting workflows is a bit more tricky, you will have to first completely delete all dependent entries to not break things. I advise against deleting certificates, but if you do so, you will also need to delete dependent certificate_attributes. > Also is it possible to configure the level of logs? All internal logging is done via Log4Perl, and the corresponding log configuration is located at /etc/openxpk/log.conf - adapt log levels and log targets to your liking. Cheers Martin |
|
From: Alaa H. <ala...@gm...> - 2026-03-04 09:31:33
|
Thank you for your reply. Is it safe to clear the application log and the workflow history manually from the database? Also is it possible to configure the level of logs? Best Regards, On Wed, Mar 4, 2026 at 10:28 AM Martin Bartosch via OpenXPKI-users < ope...@li...> wrote: > Hi, > > > On Fri, Feb 27, 2026 at 3:30 PM Alaa Hilal <ala...@gm...> wrote: > > Hello, > > > > I have been using OpenXPKI for a while and in general all going well. > The size of the database has grown large. Specifically the tables: > > - workflow_context > > - workflow_history > > - certificate > > - application_log > > > > Obviously as we use the system more, the size will grow, however, I > wanted to check if there are any functions or commands that we can use to > make some cleanups on old data that is not needed anymore. > > > In our opinion the PKI should be able to provide information on issued > certificates, so from my point of view deleting certificates is a no-go. > The OpenXPKI design philosophy was to establish accountability on the PKI > operations, which also means that workflow instances, history and context > do provide useful information on the request and decision process on > certificate issuance. > > However, it is of course possible to clean up the database if so desired. > For high volume installations we have implemented a cleanup mechanism which > can be set up to regularly truncate/archive workflows (but not > certificates) from the database. However, this solution is only available > in the Enterprise Edition, so I am afraid you will have to roll your own > cleanup procedure. > > Cheers > > Martin > > > > > _______________________________________________ > OpenXPKI-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openxpki-users > |
|
From: Martin B. <vc...@cy...> - 2026-03-04 09:28:43
|
Hi, > I want to focus now on a simpler path, so remove the default CA in "democa" and replace it with our own. Is it possible? Everything works, but the fact is that in the OpenXPKI server, the token appears as offline. Do you have any suggestions on why it is happening? Check the log file, it should indicate the cause of the problem. Cheers Martin |
|
From: Martin B. <vc...@cy...> - 2026-03-04 09:26:59
|
Hi, > On Fri, Feb 27, 2026 at 3:30 PM Alaa Hilal <ala...@gm...> wrote: > Hello, > > I have been using OpenXPKI for a while and in general all going well. The size of the database has grown large. Specifically the tables: > - workflow_context > - workflow_history > - certificate > - application_log > > Obviously as we use the system more, the size will grow, however, I wanted to check if there are any functions or commands that we can use to make some cleanups on old data that is not needed anymore. In our opinion the PKI should be able to provide information on issued certificates, so from my point of view deleting certificates is a no-go. The OpenXPKI design philosophy was to establish accountability on the PKI operations, which also means that workflow instances, history and context do provide useful information on the request and decision process on certificate issuance. However, it is of course possible to clean up the database if so desired. For high volume installations we have implemented a cleanup mechanism which can be set up to regularly truncate/archive workflows (but not certificates) from the database. However, this solution is only available in the Enterprise Edition, so I am afraid you will have to roll your own cleanup procedure. Cheers Martin |
|
From: Alaa H. <ala...@gm...> - 2026-03-04 08:47:48
|
Hello, Apologies to bother again, but just checking if there is any info about this topic Best Regards, On Fri, Feb 27, 2026 at 3:30 PM Alaa Hilal <ala...@gm...> wrote: > Hello, > > I have been using OpenXPKI for a while and in general all going well. The > size of the database has grown large. Specifically the tables: > - workflow_context > - workflow_history > - certificate > - application_log > > Obviously as we use the system more, the size will grow, however, I wanted > to check if there are any functions or commands that we can use to make > some cleanups on old data that is not needed anymore. > > Best Regards, > |
|
From: Robert B. <bl...@ib...> - 2026-02-27 14:35:26
|
Guten Tag, vielen Dank für Ihre Nachricht. Ich bin bis zum 27.02.2026 leider nicht im Hause, kümmere mich aber gerne gleich nach meiner Rückkehr um Ihr Schreiben. Ihre Nachricht wird nicht automatisch weitergeleitet. Im Falle unaufschiebbarer Anliegen schreiben Sie bitte an tt...@ib... Vielen Dank für Ihr Verständnis. Mit freundlichen Grüßen Robert Bloch IBI - Institut für Bildung in der Informationsgesellschaft gGmbH Salzufer 22 10587 Berlin Fon Zentrale 030 – 330 99 89 - 0 Meine Durchwahl 030 – 330 99 89 -17 Fax 030 – 330 99 89 01 www.ibi.tu-berlin.de Wissenschaftlicher Direktor Prof. Dr. Ulf Schrader Geschäftsführer Morten Hendricks Registergericht Berlin-Charlottenburg Registernummer HRB 160074 B Steuernummer 27/640/02054 |
|
From: Alaa H. <ala...@gm...> - 2026-02-27 14:30:57
|
Hello, I have been using OpenXPKI for a while and in general all going well. The size of the database has grown large. Specifically the tables: - workflow_context - workflow_history - certificate - application_log Obviously as we use the system more, the size will grow, however, I wanted to check if there are any functions or commands that we can use to make some cleanups on old data that is not needed anymore. Best Regards, |
|
From: De B. E. (RSE-ext) <Eri...@rs...> - 2026-02-26 14:20:52
|
Thank you for the answer. The fact is that the documentation is missing a lot and it contains also errors. The batch file that we created was developed step by step using the documentation. I want to focus now on a simpler path, so remove the default CA in "democa" and replace it with our own. Is it possible? Everything works, but the fact is that in the OpenXPKI server, the token appears as offline. Do you have any suggestions on why it is happening? Best regards ________________________________ Da: Martin Bartosch via OpenXPKI-users <ope...@li...> Inviato: mercoledì 25 febbraio 2026 16:36 A: ope...@li... <ope...@li...> Cc: Martin Bartosch <vc...@cy...> Oggetto: Re: [OpenXPKI-users] Use of a custom CA [Non ricevi spesso messaggi di posta elettronica da ope...@li.... Per informazioni sull'importanza di questo fatto, visita https://aka.ms/LearnAboutSenderIdentification.] Hi Erika, > I am currently working with OpenXPKI to implement a custom certificate chain. My goal is to establish a personalized CA hierarchy directly within the system. > According to the documentation, I have proceeded with creating a new realm, generating a private key, and setting up the CA certificate. You can find the batch file containing the configuration steps I followed here below: > Unfortunately, this initial setup was unsuccessful. As a workaround, we attempted to remove the default CA in "democa" and replace it with our own. While this operation and the subsequent token creation were successful, we have encountered a critical issue: the token appears as offline within the OpenXPKI server. > Could you please advise if there is a more straightforward or better-documented procedure for importing a custom CA? Any guidance on why the token might be stuck offline would be greatly appreciated. The setup script you posted is obviously AI generated and therefore very likely defective. Please understand that we cannot assist you prompting your AI or debugging its defective output. If you wish to set up your a PKI customized to your requirements, this is very much doable with the existing documentation and the (currently still useful) trove of knowledge on the mailing list. We are happy to help you with any specific questions with regard to particular problems. Describe your problem in a way that we can understand it and we will do our best to help. Feel free to contact White Rabbit Security if you prefer a professional services with regard to design, configuration, deployment and support of a company PKI. Our OpenXPKI Enterprise Edition offer includes correctly prepared configuration, extensive documentation and fully functional setup according to your particular PKI design. Cheers Martin _______________________________________________ OpenXPKI-users mailing list Ope...@li... https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fopenxpki-users&data=05%7C02%7Cerika.debardi%40rse-web.it%7Ce260e777f2694f7d0f4108de7486d3bd%7C2de962948ad84c67b400a0d5ba661c6f%7C0%7C0%7C639076319746854497%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=OqoctkUu9oan%2B9LuUnCtgqAqn0YoKuQoDB0RxumJ420%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/openxpki-users> RSE SpA ha adottato il Modello Organizzativo ai sensi del D.Lgs.231/2001, in forza del quale l'assunzione di obbligazioni da parte della Società avviene con firma di un procuratore, munito di idonei poteri. RSE adopts a Compliance Programme under the Italian Law (D.Lgs.231/2001). According to this RSE Compliance Programme, any commitment of RSE is taken by the signature of one Representative granted by a proper Power of Attorney. Le informazioni contenute in questo messaggio di posta elettronica sono riservate e confidenziali e ne e' vietata la diffusione in qualsiasi modo o forma. Qualora Lei non fosse la persona destinataria del presente messaggio, La invitiamo a non diffonderlo e ad eliminarlo, dandone gentilmente comunicazione al mittente. The information included in this e-mail and any attachments are confidential and may also be privileged. If you are not the correct recipient, you are kindly requested to notify the sender immediately, to cancel it and not to disclose the contents to any other person. |
|
From: Martin B. <vc...@cy...> - 2026-02-25 15:55:33
|
Hi Erika, > I am currently working with OpenXPKI to implement a custom certificate chain. My goal is to establish a personalized CA hierarchy directly within the system. > According to the documentation, I have proceeded with creating a new realm, generating a private key, and setting up the CA certificate. You can find the batch file containing the configuration steps I followed here below: > Unfortunately, this initial setup was unsuccessful. As a workaround, we attempted to remove the default CA in "democa" and replace it with our own. While this operation and the subsequent token creation were successful, we have encountered a critical issue: the token appears as offline within the OpenXPKI server. > Could you please advise if there is a more straightforward or better-documented procedure for importing a custom CA? Any guidance on why the token might be stuck offline would be greatly appreciated. The setup script you posted is obviously AI generated and therefore very likely defective. Please understand that we cannot assist you prompting your AI or debugging its defective output. If you wish to set up your a PKI customized to your requirements, this is very much doable with the existing documentation and the (currently still useful) trove of knowledge on the mailing list. We are happy to help you with any specific questions with regard to particular problems. Describe your problem in a way that we can understand it and we will do our best to help. Feel free to contact White Rabbit Security if you prefer a professional services with regard to design, configuration, deployment and support of a company PKI. Our OpenXPKI Enterprise Edition offer includes correctly prepared configuration, extensive documentation and fully functional setup according to your particular PKI design. Cheers Martin |
|
From: Robert B. <bl...@ib...> - 2026-02-25 12:22:38
|
Guten Tag, vielen Dank für Ihre Nachricht. Ich bin bis zum 27.02.2026 leider nicht im Hause, kümmere mich aber gerne gleich nach meiner Rückkehr um Ihr Schreiben. Ihre Nachricht wird nicht automatisch weitergeleitet. Im Falle unaufschiebbarer Anliegen schreiben Sie bitte an tt...@ib... Vielen Dank für Ihr Verständnis. Mit freundlichen Grüßen Robert Bloch IBI - Institut für Bildung in der Informationsgesellschaft gGmbH Salzufer 22 10587 Berlin Fon Zentrale 030 – 330 99 89 - 0 Meine Durchwahl 030 – 330 99 89 -17 Fax 030 – 330 99 89 01 www.ibi.tu-berlin.de Wissenschaftlicher Direktor Prof. Dr. Ulf Schrader Geschäftsführer Morten Hendricks Registergericht Berlin-Charlottenburg Registernummer HRB 160074 B Steuernummer 27/640/02054 |
|
From: Robert B. <bl...@ib...> - 2026-02-25 12:20:28
|
Guten Tag, vielen Dank für Ihre Nachricht. Ich bin bis zum 27.02.2026 leider nicht im Hause, kümmere mich aber gerne gleich nach meiner Rückkehr um Ihr Schreiben. Ihre Nachricht wird nicht automatisch weitergeleitet. Im Falle unaufschiebbarer Anliegen schreiben Sie bitte an tt...@ib... Vielen Dank für Ihr Verständnis. Mit freundlichen Grüßen Robert Bloch IBI - Institut für Bildung in der Informationsgesellschaft gGmbH Salzufer 22 10587 Berlin Fon Zentrale 030 – 330 99 89 - 0 Meine Durchwahl 030 – 330 99 89 -17 Fax 030 – 330 99 89 01 www.ibi.tu-berlin.de Wissenschaftlicher Direktor Prof. Dr. Ulf Schrader Geschäftsführer Morten Hendricks Registergericht Berlin-Charlottenburg Registernummer HRB 160074 B Steuernummer 27/640/02054 |
|
From: De B. E. (RSE-ext) <Eri...@rs...> - 2026-02-25 12:15:43
|
Good morning,
I am currently working with OpenXPKI to implement a custom certificate chain. My goal is to establish a personalized CA hierarchy directly within the system.
According to the documentation, I have proceeded with creating a new realm, generating a private key, and setting up the CA certificate. You can find the batch file containing the configuration steps I followed here below:
set -euo pipefail
REALM_DIR="/etc/openxpki/ca/mia_ca"
REALM_NAME="mia_ca"
CONFIG_REALM_DIR="/etc/openxpki/config.d/realm/${REALM_NAME}"
SYSTEM_REALMS_FILE="/etc/openxpki/config.d/system/realms.yaml"
DEMO_DIR="/etc/openxpki/config.d/realm/democa"
CRYPTO_YAML="${CONFIG_REALM_DIR}/crypto.yaml"
CA_KEY="${REALM_DIR}/ca.key"
CA_CRT="${REALM_DIR}/ca.crt"
echo "Creazione directory per la CA: ${REALM_DIR}"
sudo mkdir -p "${REALM_DIR}"
echo "Generazione chiave privata"
sudo openssl genrsa -out "${CA_KEY}" 4096
sudo chmod 600 "${CA_KEY}"
echo "Generazione cert CA"
sudo openssl req -x509 -new -nodes -key "${CA_KEY}" -sha256 -days 3650 -subj "/CN=Mia Ca Interna/O=MiaAzienda/C=IT" -out "${CA_CRT}"
sudo chown root:root "${REALM_DIR}"/* || true
sudo chmod 644 "${CA_CRT}" || true
if [ -d "${DEMO_DIR}" ]; then
echo "Copia struttura democa in ${CONFIG_REALM_DIR}"
sudo cp -r "${DEMO_DIR}" "${CONFIG_REALM_DIR}"
else
echo "Attenzione: ${DEMO_DIR} non esiste"
sudo mkdir -p "${CONFIG_REALM_DIR}"
sudo mkdir -p "${CONFIG_REALM_DIR}/profile"
sudo mkdir -p "${CONFIG_REALM_DIR}/auth"
fi
if [ -f "${CRYPTO_YAML}" ]; then
echo "Rimuovo ${CRYPTO_YAML}"
sudo rm -f "${CRYPTO_YAML}"
fi
echo "Creazione ${CRYPTO_YAML}"
sudo tee "${CRYPTO_YAML}" > /dev/null <<YAML
type:
certsign: mia_ca_signer
token:
default:
backend: OpenSSL
engine: OpenSSL
key: /etc/openxpki/ca/mia_ca/ca.key
cert: /etc/openxpki/ca/mia_ca/ca.cert
YAML
sudo chmod 640 "${CRYPTO_YAML}"
AUTH_HANDLER="${CONFIG_REALM_DIR}/auth/handler.yaml"
echo "Creazione handler in ${AUTH_HANDLER}"
sudo tee "${AUTH_HANDLER}" > /dev/null <<'YAML'
Anonymous:
type: Anonymous
label: Anonymous
System:
type: Anonymous
label: System
Certificate:
type: ClientX509
role: User
arg: CN
trust_anchor:
realm: mia_ca
LocalPassword:
type: Password
user@: connector:auth.connector.userdb
Password:
type: Password
user:
emma:
digest: '{plain}admin123'
role: user
caop:
digest: '{plain}admin123'
role: CA operator
raop:
digest: '{plain}admin123'
role: RA operator
YAML
sudo chmod 640 "${AUTH_HANDLER}"
if grep -q "^${REALM_NAME}:" "${SYSTEM_REALMS_FILE}" 2>/dev/null; then
echo "Realm ${REALM_NAME} già presente in ${SYSTEM_REALMS_FILE}"
else
echo "Aggiungo ${REALM_NAME} a ${SYSTEM_REALMS_FILE}"
sudo mkdir -p "$(dirname "${SYSTEM_REALMS_FILE}")"
sudo tee -a "${SYSTEM_REALMS_FILE}" > /dev/null <<YAML
${REALM_NAME}:
label: Mia CA Interna
baseurl: https://localhost/webui
YAML
fi
if command -v openxpkiadm >/dev/null 2>&1; then
echo "Verifica realm con 'sudo openxpki certificate list --realm ${REALM_NAME}'"
sudo openxpkiadm certificate list --realm "${REALM_NAME}" || true
else
echo "openxpki non trovato"
fi
if command -v openxpkiadm >/dev/null 2>&1; then
echo "import della CA"
IMPORT_OUTPUT=$(sudo openxpkiadm certificate import --realm "${REALM_NAME}" --file "${CA_CRT}" 2>&1)
echo "${IMPORT_OUTPUT}"
IDENTIFIER=$(echo "${IMPORT_OUTPUT}" | grep -i "identifier" | sed 's/.*identifier[: ]*//i')
if [ -n "$IDENTIFIER" ]; then
echo "identifier trovato: $IDENTIFIER"
echo "aggiunta alias token"
sudo openxpkiadm alias --realm "${REALM_NAME}" --identifier "$IDENTIFIER" --token certsign
else
echo "Errore identfier"
fi
else
echo "Openxpkiadm non trovato"
fi
TLS_SERVER_PROFILE="${CONFIG_REALM_DIR}/profile/tls_server.yaml"
echo "Creazione profilo server in ${TLS_SERVER_PROFILE}"
sudo tee "${TLS_SERVER_PROFILE}" > /dev/null <<'YAML'
subject:
pattern: CN=%cn%,O=MiaAzienda,C=IT
fields:
cn:
label: Nome host server
description: inserisci host name server
type: freetext
extensions:
key_usage:
critical: 1
digital_signature: 1
key_encipherment: 1
extended_key_usage:
critical: 0
server_auth: 1
YAML
TLS_CLIENT_PROFILE="${CONFIG_REALM_DIR}/profile/tls_client.yaml"
echo "Creazione profilo client in ${TLS_CLIENT_PROFILE}"
sudo tee "${TLS_CLIENT_PROFILE}" > /dev/null <<'YAML'
subject:
pattern: CN=%cn%,O=MiaAzienda,C=IT
fields:
cn:
label: Nome utente
description: inserisci nome utente
type: freetext
ou:
label: unità
description: inserisci nome unità o gruppo utente
type: freetext
extensions:
key_usage:
critical: 1
digital_signature: 1
extended_key_usage:
critical: 0
client_auth: 1
YAML
exit 0
Unfortunately, this initial setup was unsuccessful. As a workaround, we attempted to remove the default CA in "democa" and replace it with our own. While this operation and the subsequent token creation were successful, we have encountered a critical issue: the token appears as offline within the OpenXPKI server.
Could you please advise if there is a more straightforward or better-documented procedure for importing a custom CA? Any guidance on why the token might be stuck offline would be greatly appreciated.
Thank you in advance for your assistance.
Best regards,
Erika
[http://signature.rse-web.it/_rse_logo.png]
Erika De Bardi
Ricerca sul Sistema Energetico - RSE S.p.A.
Via R. Rubattino 54 - 20134 Milano
www.rse-web.it<https://www.rse-web.it>
________________________________
[http://signature.rse-web.it/_Leaf.png] Pensa all'ambiente prima di stampare questa email
seguici su [http://signature.rse-web.it/_linkedin.png] <https://it.linkedin.com/company/ricerca-sul-sistema-energetico---rse-spa> [http://signature.rse-web.it/_twitter.png] <https://twitter.com/rsenergetico> [http://signature.rse-web.it/_youtube.png] <https://www.youtube.com/user/RSEmedia>
RSE SpA ha adottato il Modello Organizzativo ai sensi del D.Lgs.231/2001, in forza del quale l'assunzione di obbligazioni da parte della Società avviene con firma di un procuratore, munito di idonei poteri. RSE adopts a Compliance Programme under the Italian Law (D.Lgs.231/2001). According to this RSE Compliance Programme, any commitment of RSE is taken by the signature of one Representative granted by a proper Power of Attorney.
Le informazioni contenute in questo messaggio di posta elettronica sono riservate e confidenziali e ne e' vietata la diffusione in qualsiasi modo o forma. Qualora Lei non fosse la persona destinataria del presente messaggio, La invitiamo a non diffonderlo e ad eliminarlo, dandone gentilmente comunicazione al mittente. The information included in this e-mail and any attachments are confidential and may also be privileged. If you are not the correct recipient, you are kindly requested to notify the sender immediately, to cancel it and not to disclose the contents to any other person.
|
|
From: Oliver W. <ma...@ol...> - 2026-01-30 08:38:34
|
Hello Jan, welcome to the OpenXPKI users list :) the RPC call runs the workflow and the cert_identifier is generated as a result of the SearchCertificate call. All the other items call a plugin helper to generate other items from the certidentifier, this is simply done by looking up the artefacts in the database or parsing the certificate. If you run "perldoc OpenXPKI::Template::Plugin::Certificate" in the system you can see the embed documentation of the module with the methods it exposes (you can also browse it in the github repo - the docs are part of the code file). Its important to have the key defined in the workflow AND add it to the output section (this works as a filter to not expose any sensitive data). Oliver On 1/29/26 14:15, Jan Uyttersprot via OpenXPKI-users wrote: > questions regarding customizing workflow certificatesearch > > HI, > > > > Version : OpenXPKI Community Edition v3.32.8 > > > when using RPC to run the search certificate workflow I have the > following action defined in the workflow/def/certificate_search.yaml : > > > get_certificate_data: > class: OpenXPKI::Server::Workflow::Activity::Tools::SetContext > param: > _map_notbefore: "[% USE Certificate %][% > Certificate.notbefore(context.cert_identifier) %]" > _map_notafter: "[% USE Certificate %][% > Certificate.notafter(context.cert_identifier) %]" > _map_status: "[% USE Certificate %][% > Certificate.status(context.cert_identifier) %]" > _map_pem: "[% USE Certificate %][% > Certificate.pem(context.cert_identifier) %]" > _map_cn: "[% USE Certificate %][% > Certificate.subject(context.cert_identifier) %]" > > > > in the client.d/service/rpc/public.yaml rpc config I have > > > SearchCertificate: > workflow: certificate_search > input: > - common_name > output: > - notbefore > - notafter > - status > - pem > - cn > - cert_identifier > > > all fields are displayed in the json data array fine. > > > Can someone please explain : > > > - why I dont need to map cert_identifier to return it, cert_identifier > seems to be the only value that doesnt need to be mapped to work in > output ? > > - why I cannot do : _map_whatever: "[% USE Certificate %][% > Certificate.cert_identifier(context.cert_identifier) %]" and let it > output via the RPC call by adding '- whatever' in the output: list ? > > - why I cannot do : _map_keyid: "[% USE Certificate %][% > Certificate.subject_key_identifier(context.cert_identifier) %]" and > let it output via the RPC call by adding '- keyid' in the output: list ? > > > > just trying to make some sense of all this > > > thank you in advance > > regards, > > Jan > > > > _______________________________________________ > OpenXPKI-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openxpki-users -- Protect your environment - close windows and adopt a penguin! |
|
From: Jan U. <jan...@ti...> - 2026-01-29 13:32:26
|
HI, Version : OpenXPKI Community Edition v3.32.8 when using RPC to run the search certificate workflow I have the following action defined in the workflow/def/certificate_search.yaml : get_certificate_data: class: OpenXPKI::Server::Workflow::Activity::Tools::SetContext param: _map_notbefore: "[% USE Certificate %][% Certificate.notbefore(context.cert_identifier) %]" _map_notafter: "[% USE Certificate %][% Certificate.notafter(context.cert_identifier) %]" _map_status: "[% USE Certificate %][% Certificate.status(context.cert_identifier) %]" _map_pem: "[% USE Certificate %][% Certificate.pem(context.cert_identifier) %]" _map_cn: "[% USE Certificate %][% Certificate.subject(context.cert_identifier) %]" in the client.d/service/rpc/public.yaml rpc config I have SearchCertificate: workflow: certificate_search input: - common_name output: - notbefore - notafter - status - pem - cn - cert_identifier all fields are displayed in the json data array fine. Can someone please explain : - why I dont need to map cert_identifier to return it, cert_identifier seems to be the only value that doesnt need to be mapped to work in output ? - why I cannot do : _map_whatever: "[% USE Certificate %][% Certificate.cert_identifier(context.cert_identifier) %]" and let it output via the RPC call by adding '- whatever' in the output: list ? - why I cannot do : _map_keyid: "[% USE Certificate %][% Certificate.subject_key_identifier(context.cert_identifier) %]" and let it output via the RPC call by adding '- keyid' in the output: list ? just trying to make some sense of all this thank you in advance regards, Jan |
|
From: Thomas G. <t.g...@he...> - 2025-12-08 09:09:11
|
Hello Oliver, the problem is that the documentation has a lot of errors and is missing a lot: I really tried to follow the all steps in README.md <https://github.com/openxpki/openxpki-config/blob/community/README.md> and QUICkSTART.md <https://github.com/openxpki/openxpki-config/blob/community/QUICKSTART.md> to initial create my realm. But it is impossible to get it to work: 1.) When creating a key/cert the commands create files vault-1.pem and vault-1.crt. But already the next step uses file vault.pem and vault.crt ... (OK, not a big problem but not good, when providing a copy button) 2.) After importing the certificate I should check with ```oxi api get_token_info --realm democa -- alias=ca-signer-13```, but it creates the following error: TokenManager failed to create token for ca-signer-13; __ERRVAL__ => No certificate found for given alias; __alias__ => ca-signer-13 If I try to check the aliases for my domain with ```openxpkiadm alias --real democa``` I get: === functional token === svault (datasafe): Alias : svault-1 Identifier: 5yf1ovqpfe0p7zy8FjUmhh-L96g NotBefore : 2025-12-08 08:46:37 NotAfter : 2026-12-08 08:46:37 ca-signer (certsign): Alias : ca-signer-1 Identifier: aebqYQ1WlzrkQNPb6Tgsiq5prNY NotBefore : 2025-01-27 17:06:05 NotAfter : 2035-01-25 17:06:05 ratoken (cmcra): not set ratoken (scep): not set === root ca === current root ca: Alias : root-1 Identifier: aebqYQ1WlzrkQNPb6Tgsiq5prNY NotBefore : 2025-01-27 17:06:05 NotAfter : 2035-01-25 17:06:05 upcoming root ca: not set So there is no alias ca-signer-13 But adjusting this to ca-signer-1 gives the next error: vault instance id does not match id of encypted data Sorry, but the documentation might be helpful if you are already Openxpki professional but not for a starter with > 30 years working as a sysadmin in Linux and some experiences with PKI and certificates ... And when I can't find a solution in the docs which I always check before asking I try to ask a AI to find maybe a solution. Greetings, Thomas Am 05.12.25 um 19:37 schrieb Oliver Welter: > Hi, > > as already said - please use docs and not AI generated configs and as > your config snippets do not match the errror message it is impossible > to help. > > best regards > > Oliver > > On 12/3/25 10:07, Thomas Gebert wrote: >> Hello, >> >> I get the following error while starting the server: >> >> Dec 03 08:56:25 test-keycloak02.testing.edubw.link >> openxpkictl[278617]: Exception during server initialization: No type >> given for authentication handler BasicAuth (No type given for >> authentication handler BasicAuth) at >> /usr/share/perl5/OpenXPKI/Server.pm line 801, <DATA> line 1. >> >> But there are types given for the stack and the handler: >> >> stack.yaml: >> _System: >> handler: System >> >> default: >> handler: BasicAuth >> >> BasicAuth: >> handler: ExternalAuth >> type: NoAuth >> label: "Keycloak SSO" >> param: >> envkeys: >> username: REMOTE_USER >> email: OIDC_CLAIM_email >> role: OPENXPKI_SSO_ROLE >> >> handler.yaml: >> >> # Those stacks are usually required so you should not remove them >> Anonymous: >> type: Anonymous >> label: Anonymous >> >> System: >> type: Anonymous >> role: System >> >> # Read the userdata from a YAML file defined in auth/connector.yaml >> LocalPassword: >> type: Password >> user@: connector:auth.connector.userdb >> >> ExternalAuth: >> label: Keycloak SSO (NoAuth) >> class: OpenXPKI::Server::Authentication::NoAuth >> type: NoAuth >> >> >> So I don't understand the error in the log. >> >> What is wrong here? >> >> Kind regards, >> >> Thomas >> -- Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: 030 / 40 50 51 - 0 Fax: 030 / 40 50 51 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin |
|
From: Oliver W. <ma...@ol...> - 2025-12-05 18:46:07
|
Hello Xiao, the provided LDAP authentication connector is not able to read attributes from LDAP - it just makes a bind to check the password. There is a suitable module avail in the enterprise version, as an alternative you can use an external authentication proxy like Authelia and use it to feed the attributes via the environment. Oliver On 11/27/25 07:48, HAN Xiao wrote: > Hello Oliver, > > Thank you for your reply. > I am very sorry about the AI-generated configuration in my previous email. That was my mistake, and I fully understand your concern. I will no longer use any AI-generated config when asking questions on the mailing list. > > Regarding my issue: I have been reading the documentation on > https://openxpki.readthedocs.io/en/master/ > > but I may have overlooked the relevant part. What I am trying to understand is: > > How to correctly map LDAP attributes (e.g. firstName, lastName, email) to OpenXPKI user attributes such as userinfo.* for TestAccounts, and how these mapped values can be used in profile presets. > > If this is already described somewhere in the documentation, could you please let me know where to find it? I would really appreciate even a small pointer, and I apologize again if the information is already there and I simply missed it. > > Thank you very much for your time, and sorry again for the trouble caused. > > Best regards, > Xiao Han > > > -----Original Messages----- > From: "Oliver Welter" <ma...@ol...> > Send time: Thursday, 11/27/2025 14:11:59 > To: ope...@li... > Subject: Re: [OpenXPKI-users] How to use attributes in LDAP as OpenXPKI user attributes > > Hello, > > please read the extensive documntation and stop spamming the ML with AI generated config. > > best regards > > Oliver > > On 11/26/25 17:41, HAN Xiao wrote: > Dear Developer, > > I encountered an issue while configuring OpenXPKI: > I’m unable to use user attributes from LDAP as user properties in presets or in other parts of the workflow. > > In detail, my LDAP connection is working and I can log in normally. The configuration is as follows: > > --stack.yaml-- > LDAPAuth: > label: LDAP Auth > description: Login with LDAP > handler: LDAPAuth > type: passwd > > --handler.yaml-- > LDAPAuth: > type: Connector > label: LDAP Login for Users > role: User > source@: connector:auth.connector.userLDAP > > attributes: > userinfo.email@: "param:email" > userinfo.gname@: "param:firstName" > userinfo.name@: "param:lastName" > > --connector.yaml-- > userLDAP: > class: Connector::Builtin::Authentication::LDAP > LOCATION: ldap://xxx.xxx.xx.xx > base: ou=users,dc=xxxx,dc=xx,dc=xx > binddn: cn=xxxx,ou=users,dc=xxxx,dc=xx,dc=xx > password: xxxx > debug: 1 > verify: none > filter: "(email=[% LOGIN %])" > > > attrs: > - email > - firstName > - lastName > > > > The LDAP contains the following information that I need: > > email: ha...@ih... > lastName: Han > firstName: Xiao > sex: male > sn: hanx14 > afs: hanx > > But I don't know how to use it in realm/realm_name/profile/template/ > I just do some simple test, like > > --requestor_gname.yaml-- > id: requestor_gname > label: I18N_OPENXPKI_UI_PROFILE_REQUESTOR_REALNAME > description: I18N_OPENXPKI_UI_PROFILE_REQUESTOR_REALNAME_DESC > type: static > width: 40 > placeholder: John Doe > preset: userinfo.gname > required: 0 > > However, in the web UI it shows as <not set>. > > Additionally, there are a large number of errors in /var/log/openxpki-server/catchall.log and openxpki.log: > 2025/11/27 00:09:01 FATAL OpenXPKI::Service::Default->init() failed: I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=370|sid=OHJK] > 2025/11/27 00:09:01 openxpki.system.FATAL OpenXPKI::Service::Default->init() failed: I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=370|sid=OHJK] > > I’m not sure if these are related to the issue. > > I look forward to your help. Thank you! > > Best regards, > Xiao HAN > > > > _______________________________________________ > OpenXPKI-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openxpki-users -- Protect your environment - close windows and adopt a penguin! |
|
From: Oliver W. <ma...@ol...> - 2025-12-05 18:38:02
|
Hi, as already said - please use docs and not AI generated configs and as your config snippets do not match the errror message it is impossible to help. best regards Oliver On 12/3/25 10:07, Thomas Gebert wrote: > Hello, > > I get the following error while starting the server: > > Dec 03 08:56:25 test-keycloak02.testing.edubw.link > openxpkictl[278617]: Exception during server initialization: No type > given for authentication handler BasicAuth (No type given for > authentication handler BasicAuth) at > /usr/share/perl5/OpenXPKI/Server.pm line 801, <DATA> line 1. > > But there are types given for the stack and the handler: > > stack.yaml: > _System: > handler: System > > default: > handler: BasicAuth > > BasicAuth: > handler: ExternalAuth > type: NoAuth > label: "Keycloak SSO" > param: > envkeys: > username: REMOTE_USER > email: OIDC_CLAIM_email > role: OPENXPKI_SSO_ROLE > > handler.yaml: > > # Those stacks are usually required so you should not remove them > Anonymous: > type: Anonymous > label: Anonymous > > System: > type: Anonymous > role: System > > # Read the userdata from a YAML file defined in auth/connector.yaml > LocalPassword: > type: Password > user@: connector:auth.connector.userdb > > ExternalAuth: > label: Keycloak SSO (NoAuth) > class: OpenXPKI::Server::Authentication::NoAuth > type: NoAuth > > > So I don't understand the error in the log. > > What is wrong here? > > Kind regards, > > Thomas > -- Protect your environment - close windows and adopt a penguin! |
|
From: Oliver W. <ma...@ol...> - 2025-12-05 18:27:00
|
The very likely reason is, that reading of docs is better then using AI.... https://openxpki.readthedocs.io/en/master/configuration/realm.html#authentication On 12/5/25 16:19, Alexander Dersch via OpenXPKI-users wrote: > Hello, > > I am having problems with the user authentication via LDAPS to an MSFT Active Directory. The problems is that I do not see any packets reaching the AD server from the OpenXPKI server. The openssl s_client -connect dc01.linuxlab.lan:636 -showcerts </dev/null test was successful. What do I miss? Thanks in advance. > > Alex > > The OpenXPKI system is installed as container on a RHEL 9 system. > I have configured so far the stack.yaml config as follows > > # --- Linuxlab AD stack --- > > linuxlab_ad_user: > label: Linuxlab AD Login - Users > description: "Login using AD account (User-Cert-Eligible)" > handler: > - ldap_linuxlab_user > type: passwd > > linuxlab_ad_ra: > label: Linuxlab AD Login - Cert Managers > description: "Login using AD account (PKI-CertManagers – approvals)" > handler: > - ldap_linuxlab_ra > type: passwd > > # --- End Linuxlab AD stack — > > and the handler.yaml as follows > > ldap_linuxlab_user: > type: Password > label: "Linuxlab AD (Users - certificate enrollment)" > class: OpenXPKI::Server::Authentication::LDAP > role: User > param: > host: dc01.linuxlab.lan > port: 636 > base: "DC=linuxlab,DC=lan" > > binddn: "CN=svc-openxpki-ldap,OU=PKI-Service-Accounts,OU=PKI,DC=linuxlab,DC=lan" > password: "AbcarCBScGEFu6cjk*" > > # User lookup > filter: "(&(sAMAccountName=[% login %])(memberOf=CN=User-Cert-Eligible,OU=PKI-Groups,OU=LinuxLab-Groups,DC=linuxlab,DC=lan))" > > # TLS behaviour – adjust to your DC setup > use_tls: 1 # ldaps on 636 > starttls: 0 # change to 1 if you use StartTLS on 389 > timeout: 10 > verify: require > cafile: /etc/openxpki/local/certs/linuxlab/ad-ca-chain.pem > > ldap_linuxlab_ra: > type: Password > label: "Linuxlab AD (Users - certificate enrollment)" > class: OpenXPKI::Server::Authentication::LDAP > role: RA Operator > param: > host: dc01.linuxlab.lan > port: 636 > base: "DC=linuxlab,DC=lan" > > binddn: "CN=svc-openxpki-ldap,OU=PKI-Service-Accounts,OU=PKI,DC=linuxlab,DC=lan" > password: "AbcarCBScGEFu6cjk*" > > # User lookup > filter: "(&(sAMAccountName=[% login %])(memberOf=CN=PKI-CertManagers,OU=PKI-Groups,OU=LinuxLab-Groups,DC=linuxlab,DC=lan))" > > # TLS behaviour – adjust to your DC setup > use_tls: 1 # ldaps on 636 > starttls: 0 # change to 1 if you use StartTLS on 389 > timeout: 10 > verify: require > cafile: /etc/openxpki/local/certs/linuxlab/ad-ca-chain.pem > > > _______________________________________________ > OpenXPKI-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openxpki-users -- Protect your environment - close windows and adopt a penguin! |
|
From: Alexander D. <ale...@ic...> - 2025-12-05 15:35:32
|
Hello,
I am having problems with the user authentication via LDAPS to an MSFT Active Directory. The problems is that I do not see any packets reaching the AD server from the OpenXPKI server. The openssl s_client -connect dc01.linuxlab.lan:636 -showcerts </dev/null test was successful. What do I miss? Thanks in advance.
Alex
The OpenXPKI system is installed as container on a RHEL 9 system.
I have configured so far the stack.yaml config as follows
# --- Linuxlab AD stack ---
linuxlab_ad_user:
label: Linuxlab AD Login - Users
description: "Login using AD account (User-Cert-Eligible)"
handler:
- ldap_linuxlab_user
type: passwd
linuxlab_ad_ra:
label: Linuxlab AD Login - Cert Managers
description: "Login using AD account (PKI-CertManagers – approvals)"
handler:
- ldap_linuxlab_ra
type: passwd
# --- End Linuxlab AD stack —
and the handler.yaml as follows
ldap_linuxlab_user:
type: Password
label: "Linuxlab AD (Users - certificate enrollment)"
class: OpenXPKI::Server::Authentication::LDAP
role: User
param:
host: dc01.linuxlab.lan
port: 636
base: "DC=linuxlab,DC=lan"
binddn: "CN=svc-openxpki-ldap,OU=PKI-Service-Accounts,OU=PKI,DC=linuxlab,DC=lan"
password: "AbcarCBScGEFu6cjk*"
# User lookup
filter: "(&(sAMAccountName=[% login %])(memberOf=CN=User-Cert-Eligible,OU=PKI-Groups,OU=LinuxLab-Groups,DC=linuxlab,DC=lan))"
# TLS behaviour – adjust to your DC setup
use_tls: 1 # ldaps on 636
starttls: 0 # change to 1 if you use StartTLS on 389
timeout: 10
verify: require
cafile: /etc/openxpki/local/certs/linuxlab/ad-ca-chain.pem
ldap_linuxlab_ra:
type: Password
label: "Linuxlab AD (Users - certificate enrollment)"
class: OpenXPKI::Server::Authentication::LDAP
role: RA Operator
param:
host: dc01.linuxlab.lan
port: 636
base: "DC=linuxlab,DC=lan"
binddn: "CN=svc-openxpki-ldap,OU=PKI-Service-Accounts,OU=PKI,DC=linuxlab,DC=lan"
password: "AbcarCBScGEFu6cjk*"
# User lookup
filter: "(&(sAMAccountName=[% login %])(memberOf=CN=PKI-CertManagers,OU=PKI-Groups,OU=LinuxLab-Groups,DC=linuxlab,DC=lan))"
# TLS behaviour – adjust to your DC setup
use_tls: 1 # ldaps on 636
starttls: 0 # change to 1 if you use StartTLS on 389
timeout: 10
verify: require
cafile: /etc/openxpki/local/certs/linuxlab/ad-ca-chain.pem |
|
From: Thomas G. <t.g...@he...> - 2025-12-03 09:08:12
|
Hello, I get the following error while starting the server: Dec 03 08:56:25 test-keycloak02.testing.edubw.link openxpkictl[278617]: Exception during server initialization: No type given for authentication handler BasicAuth (No type given for authentication handler BasicAuth) at /usr/share/perl5/OpenXPKI/Server.pm line 801, <DATA> line 1. But there are types given for the stack and the handler: stack.yaml: _System: handler: System default: handler: BasicAuth BasicAuth: handler: ExternalAuth type: NoAuth label: "Keycloak SSO" param: envkeys: username: REMOTE_USER email: OIDC_CLAIM_email role: OPENXPKI_SSO_ROLE handler.yaml: # Those stacks are usually required so you should not remove them Anonymous: type: Anonymous label: Anonymous System: type: Anonymous role: System # Read the userdata from a YAML file defined in auth/connector.yaml LocalPassword: type: Password user@: connector:auth.connector.userdb ExternalAuth: label: Keycloak SSO (NoAuth) class: OpenXPKI::Server::Authentication::NoAuth type: NoAuth So I don't understand the error in the log. What is wrong here? Kind regards, Thomas -- Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: 030 / 40 50 51 - 0 Fax: 030 / 40 50 51 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin |
|
From: Oliver W. <ma...@ol...> - 2025-12-01 20:12:33
|
Hi Thomas, AI does not play well with OpenXPKI Config - there is no such parameter like username_env You can either use REMOTE_USER or OPENXPKI_USER, passing other envvars is described here https://openxpki.readthedocs.io/en/master/configuration/realm.html#stack BasicAuth: handler: NoAuth type: client envkeys: email: AUTH_PROVIDER_email_field You must pass "username" and "role" via ENV - and if you are using the new setup with Mojolicious you need to passthru the headers to the socket. Easier solution: Get an EE License, there is a ready to use OIDC module included ;) Oliver On 12/1/25 11:54, Thomas Gebert wrote: > Hello, > > I'm trying for days now to complete my setup for an authentication > with keycloak and Apache2. > > Login over keycloak works and the apache logs show that all need > information (username, email) is set by apache. > > But I can't get the setup on the Openxpki side to work. > > Here are my settings: > > Apache2: > > <VirtualHost *:443> > > ServerAlias * > DocumentRoot /var/www/ > > RewriteEngine On > > LogFormat "%h %l %{REMOTE_USER}e %{HTTP_X_REMOTE_USER}e > %{OPENXPKI_SSO_ROLE}e %t \"%r\" %>s %b" openxpki_debug > CustomLog /var/log/apache2/openxpki_debug.log openxpki_debug > > > > SSLEngine On > SSLCertificateFile '/etc/certs/default_cert.crt' > SSLCertificateKeyFile '/etc/certs/default_key.key' > > SSLCACertificateFile /etc/certs/ca_selfsigned.crt > SSLVerifyClient optional_no_ca > SSLVerifyDepth 3 > SSLOptions +StdEnvVars +ExportCertData > > # HTTPS specific preparation for Mojolicious based client services > <IfModule mod_headers.c> > Use OxiForwardEnv SSL_CLIENT_S_DN > Use OxiForwardEnv SSL_CLIENT_CERT > </IfModule> > > # Minimum mod_auth_openidc configuration > OIDCProviderMetadataURL > https://<keycloak-machine>:8443/realms/<myrealm>/.well-known/openid-configuration > OIDCClientID openxpki > OIDCClientSecret "mypassword" > OIDCRedirectURI "https://<keycloak02-machine>/oidc_callback" > OIDCCryptoPassphrase "mypassphrase" > OIDCRemoteUserClaim preferred_username > OIDCScope "openid profile email" > OIDCPassClaimsAs environment > > # GLOBAL after OIDC, bfore Proxy! > RequestHeader set X-Remote-User "%{OIDC_CLAIM_preferred_username}e" > RequestHeader set X-Email "%{OIDC_CLAIM_email}e" > RewriteRule .* - [E=OPENXPKI_SSO_ROLE:User,NE] > > <Location /> > AuthType openid-connect > Require valid-user > </Location> > > <Location /oidc_callback> > AuthType openid-connect > Require valid-user > </Location> > > ... > > stack.yaml: > > _System: > handler: System > > BasicAuth: > handler: NoAuth > label: "Keycloak SSO" > param: > username_env: OIDC_CLAIM_preferred_username > role_env: OPENXPKI_SSO_ROLE > > > handler.yaml: > > # Those stacks are usually required so you should not remove them > Anonymous: > type: Anonymous > label: Anonymous > > System: > type: Anonymous > role: System > > # Read the userdata from a YAML file defined in auth/connector.yaml > LocalPassword: > type: Password > user@: connector:auth.connector.userdb > > NoAuth: > type: NoAuth > > > client.d/service/webui/default.yaml: > ... > # customize redirect target on "first contact" > # might be replaced / merged with new realm overview > login: > # Preset an auth stack to use, prevents the drop down > stack: BasicAuth > > # Redirect to a inline page handler instead of the default login > screen > # With the source module, this makes it easy to show some text > # FIXME - this is currently not working! > # page: source!html!file!login > > # Redirect to an external page, can be a local or absolute > external url > # url: https://login.example.com/ > > ... > realm: > # Controls how requests are mapped to realms > # select > # Shows a realm selection page (default if nothing is set). > # path|hostname > # Expects a map defined in the [realm] section (see below) > mode: path > > # Layout of the realm selection page: > # card > # Display realm cards in a grid (default) > # list > # Display realm cards as a vertical list > layout: card > > # fixed mode > #value: democa > > # map path compontent / hostname to realm (based on mode) > map: > # with mode: path > myrealm: myrealm > # rootca: rootca > # with mode: hostname > # demo.pki.example.com: democa > > I'm really frustrated that I can't figure out where the problem is. > > Can anybody help me on this topic? > > Kind regards, > > Thomas > -- Protect your environment - close windows and adopt a penguin! |
|
From: Thomas G. <t.g...@he...> - 2025-12-01 11:13:21
|
Hello,
I'm trying for days now to complete my setup for an authentication with
keycloak and Apache2.
Login over keycloak works and the apache logs show that all need
information (username, email) is set by apache.
But I can't get the setup on the Openxpki side to work.
Here are my settings:
Apache2:
<VirtualHost *:443>
ServerAlias *
DocumentRoot /var/www/
RewriteEngine On
LogFormat "%h %l %{REMOTE_USER}e %{HTTP_X_REMOTE_USER}e
%{OPENXPKI_SSO_ROLE}e %t \"%r\" %>s %b" openxpki_debug
CustomLog /var/log/apache2/openxpki_debug.log openxpki_debug
SSLEngine On
SSLCertificateFile '/etc/certs/default_cert.crt'
SSLCertificateKeyFile '/etc/certs/default_key.key'
SSLCACertificateFile /etc/certs/ca_selfsigned.crt
SSLVerifyClient optional_no_ca
SSLVerifyDepth 3
SSLOptions +StdEnvVars +ExportCertData
# HTTPS specific preparation for Mojolicious based client services
<IfModule mod_headers.c>
Use OxiForwardEnv SSL_CLIENT_S_DN
Use OxiForwardEnv SSL_CLIENT_CERT
</IfModule>
# Minimum mod_auth_openidc configuration
OIDCProviderMetadataURL
https://<keycloak-machine>:8443/realms/<myrealm>/.well-known/openid-configuration
OIDCClientID openxpki
OIDCClientSecret "mypassword"
OIDCRedirectURI "https://<keycloak02-machine>/oidc_callback"
OIDCCryptoPassphrase "mypassphrase"
OIDCRemoteUserClaim preferred_username
OIDCScope "openid profile email"
OIDCPassClaimsAs environment
# GLOBAL after OIDC, bfore Proxy!
RequestHeader set X-Remote-User "%{OIDC_CLAIM_preferred_username}e"
RequestHeader set X-Email "%{OIDC_CLAIM_email}e"
RewriteRule .* - [E=OPENXPKI_SSO_ROLE:User,NE]
<Location />
AuthType openid-connect
Require valid-user
</Location>
<Location /oidc_callback>
AuthType openid-connect
Require valid-user
</Location>
...
stack.yaml:
_System:
handler: System
BasicAuth:
handler: NoAuth
label: "Keycloak SSO"
param:
username_env: OIDC_CLAIM_preferred_username
role_env: OPENXPKI_SSO_ROLE
handler.yaml:
# Those stacks are usually required so you should not remove them
Anonymous:
type: Anonymous
label: Anonymous
System:
type: Anonymous
role: System
# Read the userdata from a YAML file defined in auth/connector.yaml
LocalPassword:
type: Password
user@: connector:auth.connector.userdb
NoAuth:
type: NoAuth
client.d/service/webui/default.yaml:
...
# customize redirect target on "first contact"
# might be replaced / merged with new realm overview
login:
# Preset an auth stack to use, prevents the drop down
stack: BasicAuth
# Redirect to a inline page handler instead of the default login screen
# With the source module, this makes it easy to show some text
# FIXME - this is currently not working!
# page: source!html!file!login
# Redirect to an external page, can be a local or absolute external url
# url: https://login.example.com/
...
realm:
# Controls how requests are mapped to realms
# select
# Shows a realm selection page (default if nothing is set).
# path|hostname
# Expects a map defined in the [realm] section (see below)
mode: path
# Layout of the realm selection page:
# card
# Display realm cards in a grid (default)
# list
# Display realm cards as a vertical list
layout: card
# fixed mode
#value: democa
# map path compontent / hostname to realm (based on mode)
map:
# with mode: path
myrealm: myrealm
# rootca: rootca
# with mode: hostname
# demo.pki.example.com: democa
I'm really frustrated that I can't figure out where the problem is.
Can anybody help me on this topic?
Kind regards,
Thomas
--
Heinlein Consulting GmbH
Schwedter Str. 8/9b, 10119 Berlin
https://www.heinlein-support.de
Tel: 030 / 40 50 51 - 0
Fax: 030 / 40 50 51 - 19
Amtsgericht Berlin-Charlottenburg - HRB 220009 B
Geschäftsführer: Peer Heinlein - Sitz: Berlin
|
|
From: HAN X. <ha...@ih...> - 2025-11-27 06:49:10
|
Hello Oliver, Thank you for your reply. I am very sorry about the AI-generated configuration in my previous email. That was my mistake, and I fully understand your concern. I will no longer use any AI-generated config when asking questions on the mailing list. Regarding my issue: I have been reading the documentation on https://openxpki.readthedocs.io/en/master/ but I may have overlooked the relevant part. What I am trying to understand is: How to correctly map LDAP attributes (e.g. firstName, lastName, email) to OpenXPKI user attributes such as userinfo.* for TestAccounts, and how these mapped values can be used in profile presets. If this is already described somewhere in the documentation, could you please let me know where to find it? I would really appreciate even a small pointer, and I apologize again if the information is already there and I simply missed it. Thank you very much for your time, and sorry again for the trouble caused. Best regards, Xiao Han -----Original Messages----- From: "Oliver Welter" <ma...@ol...> Send time: Thursday, 11/27/2025 14:11:59 To: ope...@li... Subject: Re: [OpenXPKI-users] How to use attributes in LDAP as OpenXPKI user attributes Hello, please read the extensive documntation and stop spamming the ML with AI generated config. best regards Oliver On 11/26/25 17:41, HAN Xiao wrote: Dear Developer, I encountered an issue while configuring OpenXPKI: I’m unable to use user attributes from LDAP as user properties in presets or in other parts of the workflow. In detail, my LDAP connection is working and I can log in normally. The configuration is as follows: --stack.yaml-- LDAPAuth: label: LDAP Auth description: Login with LDAP handler: LDAPAuth type: passwd --handler.yaml-- LDAPAuth: type: Connector label: LDAP Login for Users role: User source@: connector:auth.connector.userLDAP attributes: userinfo.email@: "param:email" userinfo.gname@: "param:firstName" userinfo.name@: "param:lastName" --connector.yaml-- userLDAP: class: Connector::Builtin::Authentication::LDAP LOCATION: ldap://xxx.xxx.xx.xx base: ou=users,dc=xxxx,dc=xx,dc=xx binddn: cn=xxxx,ou=users,dc=xxxx,dc=xx,dc=xx password: xxxx debug: 1 verify: none filter: "(email=[% LOGIN %])" attrs: - email - firstName - lastName The LDAP contains the following information that I need: email: ha...@ih... lastName: Han firstName: Xiao sex: male sn: hanx14 afs: hanx But I don't know how to use it in realm/realm_name/profile/template/ I just do some simple test, like --requestor_gname.yaml-- id: requestor_gname label: I18N_OPENXPKI_UI_PROFILE_REQUESTOR_REALNAME description: I18N_OPENXPKI_UI_PROFILE_REQUESTOR_REALNAME_DESC type: static width: 40 placeholder: John Doe preset: userinfo.gname required: 0 However, in the web UI it shows as <not set>. Additionally, there are a large number of errors in /var/log/openxpki-server/catchall.log and openxpki.log: 2025/11/27 00:09:01 FATAL OpenXPKI::Service::Default->init() failed: I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=370|sid=OHJK] 2025/11/27 00:09:01 openxpki.system.FATAL OpenXPKI::Service::Default->init() failed: I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=370|sid=OHJK] I’m not sure if these are related to the issue. I look forward to your help. Thank you! Best regards, Xiao HAN _______________________________________________ OpenXPKI-users mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openxpki-users -- Protect your environment - close windows and adopt a penguin! |
|
From: Oliver W. <ma...@ol...> - 2025-11-27 06:12:14
|
Hello, please read the extensive documntation and stop spamming the ML with AI generated config. best regards Oliver On 11/26/25 17:41, HAN Xiao wrote: > > Dear Developer, > > > I encountered an issue while configuring OpenXPKI: > > I’m unable to use user attributes from LDAP as user properties in > presets or in other parts of the workflow. > > > In detail, my LDAP connection is working and I can log in normally. > The configuration is as follows: > > > --stack.yaml-- > > LDAPAuth: > > label: LDAP Auth > > description: Login with LDAP > > handler: LDAPAuth > > type: passwd > > > --handler.yaml-- > LDAPAuth: > > type: Connector > > label: LDAP Login for Users > > role: User > > source@: connector:auth.connector.userLDAP > > > attributes: > > userinfo.email@: "param:email" > > userinfo.gname@: "param:firstName" > > userinfo.name@: "param:lastName" > > > --connector.yaml-- > > userLDAP: > > class: Connector::Builtin::Authentication::LDAP > > LOCATION: ldap://xxx.xxx.xx.xx > > base: ou=users,dc=xxxx,dc=xx,dc=xx > > binddn: cn=xxxx,ou=users,dc=xxxx,dc=xx,dc=xx > > password: xxxx > > debug: 1 > > verify: none > > filter: "(email=[% LOGIN %])" > > > > attrs: > > - email > > - firstName > > - lastName > > > > > The LDAP contains the following information that I need: > > > email: ha...@ih... > > lastName: Han > > firstName: Xiao > > sex: male > > sn: hanx14 > > afs: hanx > > > But I don't know how to use it in realm/realm_name/profile/template/ > > I just do some simple test, like > > > --requestor_gname.yaml-- > > id: requestor_gname > > label: I18N_OPENXPKI_UI_PROFILE_REQUESTOR_REALNAME > > description: I18N_OPENXPKI_UI_PROFILE_REQUESTOR_REALNAME_DESC > > type: static > > width: 40 > > placeholder: John Doe > > preset: userinfo.gname > > required: 0 > > > However, in the web UI it shows as |<not set>|. > > > Additionally, there are a large number of errors in > |/var/log/openxpki-server/catchall.log| and |openxpki.log:| > > 2025/11/27 00:09:01 FATAL OpenXPKI::Service::Default->init() failed: > I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION > [pid=370|sid=OHJK] > > 2025/11/27 00:09:01 openxpki.system.FATAL > OpenXPKI::Service::Default->init() failed: > I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION > [pid=370|sid=OHJK] > > > I’m not sure if these are related to the issue. > > > I look forward to your help. Thank you! > > > Best regards, > > Xiao HAN > > > > > _______________________________________________ > OpenXPKI-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openxpki-users -- Protect your environment - close windows and adopt a penguin! |
|
From: HAN X. <ha...@ih...> - 2025-11-26 16:41:46
|
Dear Developer,
I encountered an issue while configuring OpenXPKI:
I’m unable to use user attributes from LDAP as user properties in presets or in other parts of the workflow.
In detail, my LDAP connection is working and I can log in normally. The configuration is as follows:
--stack.yaml--
LDAPAuth:
label: LDAP Auth
description: Login with LDAP
handler: LDAPAuth
type: passwd
--handler.yaml--
LDAPAuth:
type: Connector
label: LDAP Login for Users
role: User
source@: connector:auth.connector.userLDAP
attributes:
userinfo.email@: "param:email"
userinfo.gname@: "param:firstName"
userinfo.name@: "param:lastName"
--connector.yaml--
userLDAP:
class: Connector::Builtin::Authentication::LDAP
LOCATION: ldap://xxx.xxx.xx.xx
base: ou=users,dc=xxxx,dc=xx,dc=xx
binddn: cn=xxxx,ou=users,dc=xxxx,dc=xx,dc=xx
password: xxxx
debug: 1
verify: none
filter: "(email=[% LOGIN %])"
attrs:
- email
- firstName
- lastName
The LDAP contains the following information that I need:
email: ha...@ih...
lastName: Han
firstName: Xiao
sex: male
sn: hanx14
afs: hanx
But I don't know how to use it in realm/realm_name/profile/template/
I just do some simple test, like
--requestor_gname.yaml--
id: requestor_gname
label: I18N_OPENXPKI_UI_PROFILE_REQUESTOR_REALNAME
description: I18N_OPENXPKI_UI_PROFILE_REQUESTOR_REALNAME_DESC
type: static
width: 40
placeholder: John Doe
preset: userinfo.gname
required: 0
However, in the web UI it shows as <not set>.
Additionally, there are a large number of errors in /var/log/openxpki-server/catchall.log and openxpki.log:
2025/11/27 00:09:01 FATAL OpenXPKI::Service::Default->init() failed: I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=370|sid=OHJK]
2025/11/27 00:09:01 openxpki.system.FATAL OpenXPKI::Service::Default->init() failed: I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=370|sid=OHJK]
I’m not sure if these are related to the issue.
I look forward to your help. Thank you!
Best regards,
Xiao HAN
|