Hello Henri, you have to use "serialNumber" as preset also, SN is the "Surname" OID :)
For the second part - you can turn on the "copy extension" flag but as outlined in the comment this copies ANYTHING from the request so this requires a certain portion of control on CSR generation and a very good validation as you otherwise might sign things you do not expect too.
The other option requires a modification of the workflow and the use of OpenXPKI::Server::Workflow::Activity::Tools::AddCertExtension, likely with some magic around to build the right content - or an upgrade to the enterprise edition which comes with a templating mechanism and some other nice features around profile based extensions.
best regards Oliver On 15.02.24 20:14, [email protected] wrote:
I'm trying to make a new certificate profile, with this kind of requirements: - Subject shall have serialNumber field, which is copied from CSR - Extensions shall have a custom OID field with custom bit stream data, which is copied from CSR I haven't been able to get any of that working. I added to templates serial.yaml: -- id: serialNumber label: serialNumber description: Serial Number preset: SN.0 type: text width: 40 placeholder: 0000 -- And I made new profile like this: -- # The name of the file equals the name of the profile label: License # digest to use digest: sha256 style: 00_basic_style: label: I18N_OPENXPKI_UI_PROFILE_BASIC_STYLE_LABEL description: I18N_OPENXPKI_UI_PROFILE_BASIC_STYLE_DESC # Define which input fields you want on the UI # Just put their names here and define them at the end # in the "template" section. # You can also use the template names found in the # template.yaml file, if you duplicate a name, the # local definition gets precedence. ui: subject: - hostname - serial - o - c info: - requestor_realname - requestor_email - owner_contact - comment # Subject is evaluated by template toolkit with the input data from the ui.subject fields # Note: Fields which have max > 1 are always passed as array subject: dn: CN=[% hostname %],serialNumber=[% serial %] # You can use the fields from ui.subject here # this is attached to the certificate, all fields from ui can be used metadata: requestor: "[% requestor_realname %]" email: "[% requestor_email %]" owner_contact: "[% owner_contact || requestor_email %]" entity: "[% hostname FILTER lower %]"# A standard template used from the automated enrollment workflowsenroll: subject: # All RDNs from the PKCS10 containers DN are avaiable here # Items from the SAN section are also available here # Note that all items are always arrays, for the SAN the pipe is # used as separator character to split individual items later dn: CN=[% CN.0 %],serialNumber=[% SN.0 %]# metadata source items added via the "params" section of the # PersistMetadata action in the workflow are available in data # DN/SAN parts are available as defined above metadata: system_id: "[% data.cust_id %]" server_id: "[% data.server_id %]" entity: "[% CN.0.replace(':.*','') FILTER lower %]" # Consumed by RenderExtensions to add extra extensions extension: securityIdentifier: '[% ext.sid %]' certificateTemplateName: '[% ext.template_name %]' certificateTemplate: - '[% ext.template.oid %]' - '[% ext.template.major %]' - '[% ext.template.minor %]' # Profile extensions - set 0/1 as needed extensions: # Enable this to copy extensions from the CSR to the Certificate # THIS MIGHT BE DANGEROUS, see copy_extensions of openssl ca command # For security reasons hhis can NOT be set in default.yaml copy: copy basic_constraints: critical: 1 ca: 0 # only relevant with ca = 1 path_length: 0 key_usage: critical: 0 digital_signature: 0 non_repudiation: 1 key_encipherment: 0 data_encipherment: 0 key_agreement: 0 key_cert_sign: 0 crl_sign: 0 encipher_only: 0 decipher_only: 0 extended_key_usage: critical: 0 # these are OIDs, some OIDs are known and have names client_auth: 0 server_auth: 0 email_protection: 0 code_signing: 0 time_stamping: 0 ocsp_signing: 0 # Any other oid can be given by number 1.3.6.1.4.1.311.20.2.2: 0 subject_key_identifier: critical: 0 hash: 1 authority_key_identifier: critical: 0 keyid: 1 issuer: 1 issuer_alt_name: critical: 0 copy: 0 crl_distribution_points: critical: 0 # uri can be scalar or list uri: - http://localhost/cacrl.crt - ldap://localhost/cn=[% ISSUER.CN.0 %],dc=OpenXPKI,dc=org authority_info_access: critical: 0 # ca_issuers and ocsp can be scalar or list ca_issuers: http://localhost/cacert.cer ocsp: http://ocsp.openxpki.org/ oid: 1.2.3.4.5.6: critical: 1 copy: 1 # end of extensions # Define the input fields you used below here #template: -- The CSR looks like this: -- Certificate Request: Data: Version: 1 (0x0) Subject: CN=Device01, O=xxxx inc/serialNumber=1234567 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: xxxx ASN1 OID: secp384r1 NIST CURVE: P-384 Attributes: Requested Extensions: 1.2.3.4.5.6: critical xxxxxx Signature Algorithm: ecdsa-with-SHA256 Signature Value: xxxx -- So far I've only tried the manual workflow. I can see it loads the serial.yaml since it puts the placeholder data and labels in there, but the serialnumber data from CSR is not filled. For the custom OID I'm not that far yet since it fails to the serial. Any idea what should be changed? Is the serial number even properly supported? //HS _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
-- Protect your environment - close windows and adopt a penguin! _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
