Hi Thomas, glad to hear its working now.
There is some documentation on "readthedocs", I guess you know this already? You can also find some slides from our workshops which give some detailed view on the internals and if you need to change things I highly recommend to read the "inline" documentation inside the yaml config as well as inside the workflow classes (perldoc is your friend). Last but not least we offer trainings and paid support and for enterprise customers there is additional training and documentation available. Help is always welcome - if you think the documentation needs improvement, fork the github repo and add some ;) best regards Oliver Am 26.04.20 um 08:03 schrieb Thomas Schachtner: > Hi Oliver, > > using "email" als id tag was working fine! > I'm wondering if there's some explanation on which directive is used for > which function? > It's quite difficult for me to understand how everyting is working and > is interfering with each other. > I now have a working setup, but I do not want to change anything as this > might break the whole setup. > > Nevertheless, I like OpenXPKI very much and if there's something I can > do to support you, please let me know. > > Best regards, > Thomas > > Am 21.04.2020 um 20:35 schrieb Oliver Welter: >> 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 >>> >> >> >> _______________________________________________ >> 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
