Hi Thomas, no this wont work, you must keep the "san" key in the subject section then it SHOULD work but I found the problem in your initial config.
The values in the ui.san section are not routed via the rendering engine but placed directly into the certificate and therefore the "id" tag must be "email" in your field definition. Oliver Am 21.04.20 um 19:47 schrieb Thomas Schachtner: > Hi Oliver, > > thanks for the answer. It's not quite clear to me, yet, what you mean. > Do you mean a policy like this? > > ui: > subject: > - realname > - email > - san_email # removed san: block and moved to subject (1) > info: > - comment > > subject: > dn: CN=[% realname %],DC=xxxx,DC=yyyy,DC=zz > email: # removed san: keyword and moved the email > block to subject > - "[% email.lower %]" > - "[% FOREACH entry = san_email %][% entry.lower %] | > [% END %]" > > I am not sure if this will work out but I can try. To be honest, I am > not really sure what's going on behind the scenes, so it's difficult for > me to guess the correct file structure... So, if you could help here > again, that would be great! > > Btw, I am using the san options quite often. Nearly every certificate I > issue has one or more SAN entries (DNS names). > > Best regards > Thomas > > Am 21.04.2020 um 17:23 schrieb Oliver Welter: >> Hi Thomas, >> >> to be honest the "extra" SAN feature has not been used for quite a while >> and is under consideration to be removed - you can just add the extra >> emails to the "subject" block which should work without any problems. >> >> best regards >> >> Oliver >> >> Am 21.04.20 um 12:39 schrieb Thomas Schachtner: >>> Hi there, >>> >>> I would like to have certificates with email addresses as Subject >>> Alternative Names. >>> With IP addresses and DNS names, this is working fine. I can add them to >>> the certificate template and they are displayed correctly as DNS: ... >>> and IP: ..., but with the SAN type "email", this is not working. >>> Is this a known issue? >>> >>> Here's the part of the policy file where I put the san part: >>> >>> style: >>> 00_user_basic_style: >>> label: I18N_OPENXPKI_UI_PROFILE_BASIC_STYLE_LABEL >>> description: I18N_OPENXPKI_UI_PROFILE_BASIC_STYLE_DESC >>> ui: >>> subject: >>> - realname >>> - email >>> san: >>> - san_email >>> info: >>> - comment >>> >>> subject: >>> dn: CN=[% realname %],DC=xxxx,DC=yyyy,DC=zz >>> san: >>> email: >>> - "[% email.lower %]" >>> - "[% FOREACH entry = san_email %][% entry.lower %] | >>> [% END %]" >>> >>> metadata: >>> requestor: "[% realname %]" >>> email: "[% email %]" >>> >>> I also have a template for san_email: >>> >>> id: san_email >>> label: I18N_OPENXPKI_UI_PROFILE_SAN_EMAILADDRESS >>> description: I18N_OPENXPKI_UI_PROFILE_SAN_EMAILADDRESS_DESC >>> type: freetext >>> match: \A .+@.+ \z >>> width: 30 >>> placeholder: [email protected] >>> min: 0 >>> max: 20 >>> >>> Is this configuration correct? >>> Is this configuration enough? >>> Should email addresses as SANs work with OpenXPKI? >>> >>> Best regards, >>> Thomas >>> >>> >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users > -- Protect your environment - close windows and adopt a penguin!
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
