I tried that, but it does not work. 
Using the template with preset as set below, it fills serialNumber field
with value "serialNumber". Certificate profile is same as I presented
before. This sounds like a bug - maybe it tries to take key instead its
value?


serial.yaml:
id: serialNumber
label: serialNumber
description: Serial Number
preset: serialNumber
type: text
width: 40
placeholder: 0000




-----Original Message-----
From: Oliver Welter <[email protected]> 
Sent: Monday, February 19, 2024 10:21 AM
To: [email protected]
Subject: Re: [OpenXPKI-users] Profile with serialNumber and custom
extensions

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 workflows
>      enroll:
>          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



_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users

Reply via email to