Greetings, Yes, I know that those fields are basically kerberos principals that FreeIPA associate certificates with. But our point of view is as follows: due to a fact that we are mostly using certificates for web applications for server auth it is not desirable to have anything except the DNS field in SAN. It seems we would have to manually issue certificates. Anyway thanks a lot for your explanation.
Regards, Alex Ivanov. On Tue, Feb 14, 2023 at 11:00 AM Alexander Bokovoy <[email protected]> wrote: > On la, 11 helmi 2023, Алексей Иванов via FreeIPA-users wrote: > >Greetings, > > > >To my knowledge it is considered a bad practice to use SAN names that are > >not associated with the principal/name you are issuing certificates for > and > >my security team is actively pushing me to remove those fields. We are > >using certificates mostly for the purpose of securing communications > >between our internal web sites. So, basically, otherName fields are not > >used in that regard. I was hoping there is a way to stop certmonger from > >adding otherNames to the csr. > > What exactly is unrelated? I think you get confused due to OpenSSL still > not supporting some SAN types in their output. > > An example -- using GnuTLS certtool I can see that the '1.3.6.1.5.2.' is > actually a KRB5Principal SAN which is totally related to the principal > tied to the host certificate: > > # certtool --infile /etc/pki/tls/certs/host-cert.crt -i |grep -A3 'Subject > Alternative Name' > Subject Alternative Name (not critical): > DNSname: some.host.name > User Principal Name: host/some.host.name@REALM > KRB5Principal: host/some.host.name@REALM > > While OpenSSL will fail to display one: > > # openssl x509 -in /etc/pki/tls/certs/host-cert.crt -text |grep -A1 > 'Subject Alternative Name' > X509v3 Subject Alternative Name: > DNS:some.host.name, othername: > UPN::host/some.host.name@REALM, othername: 1.3.6.1.5.2.2::<unsupported> > > This is just a problem with OpenSSL tools. We have been talking to > OpenSSL developers for some time but the problem (for them) is that any > SAN type that might support unicode content would need to be handled > very differently than anything else and it needs a lot of rework on the > OpenSSL side. > > What FreeIPA puts into the certificate is intended and related to the > Kerberos principals associated with the issued certificates. > > > > > >Regards, > >Alex Ivanov. > > > > > >On Wed, Feb 8, 2023 at 9:47 PM Rob Crittenden <[email protected]> > wrote: > > > >> Alex Ivanov via FreeIPA-users wrote: > >> > Greetings, > >> > > >> > I'm trying to use certmonger to automate certificate signing with > >> FreeIPA. It is working fine but it adds additional values to SAN for > issued > >> certificates > >> > > >> > Other Name: > >> > Principal Name=HTTP/<principal>@<Kerberos realm> > >> > Other Name: > >> > 1.3.6.1.5.2.2=<principal> > >> > > >> > If I choose to generate certificates using openssl and manually sign > >> them I have no such issue > >> > > >> > I've found old post about that > >> > https://lists.fedorahosted.org/archives/list/[email protected]/thread/2JOL7OAKZQXIZWIYBFNQJTXC4L2WPNAD/ > >> > > >> > Does this issue still persists or I've missed something? > >> > >> It is working as designed. > >> > >> What is the reason you don't need/want additional SAN associated with > >> the issued certificate? > >> > >> rob > >> > >> > > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > >
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
