Re: [Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fraser Tweedale]

On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote:
> Hello,
> 
> 
> 
> I would like to better understand why IPA requires SAN (subject alternative
> name) entries to have a backing host record. In order to sign a certificate
> with a SAN that corresponded to a user friendly CNAME I had to add a host
> record (ipa host) for that DNS name (use force option to create without an
> A/ record) as well as a service principle.
> 
> 
> 
> I'm sure I'm not alone when I say I don't like doing that because it means
> that a "Host" in FreeIPA is not a computer, it's a host record that may or
> may not be the only record that corresponds to a computer. It gets
> confusing.
> 
> 
> 
> I assume things are this way to ensure integrity at some level. But I can't
> picture it. What is the potential danger of simply bypassing the
> host/principal checks and just signing the certificate with whatever SAN
> field we like?
> 
In this specific case, it is because certmonger requests service
certificates with host credentials.  Therefore it is not just human
administrators issuing certs.  And we MUST validate SAN against
information in the directory (the only "source of truth" available
to the CA / IPA cert-request command).  Otherwise you could put e.g.
`google.com' into SAN, and we would issue the cert, and that would
be Very Bad.

The problem is slightly exacerbated in that 99% of the time you
really want to issue service certs, but FreeIPA does not permit the
creation of a service entry without a corresponding host entry.  So
you end up with spurious host entries that do not correspond to
actual hosts.  I have previously asked about relaxing this
restriction.  The idea was rejected (for reasons I don't remember).

> 
> 
> If this actually is a necessity and is not likely to change, I think it
> would be beneficial to administrators to be able to manage "Hosts" that
> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
> are actually enrolled computers. They could be managed in a similar fashion
> to SUDO rules, like maybe:
> 
> 
> 
> Alias Hosts = a single name
> 
> Alias Host Groups = groups of names
> 
> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups
> 
> 
> 
> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
> (and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
> under policy.
>
Now that we have kerberos principal aliases, we might be able to
leverage that, perhaps even directly for service principals.  Any
devs want to chime in on this idea?

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-cacert-manage install failing with subject public key info mismatch

[Fil Di Noto]

Hi,

Can you give an example of what's different between the two subjects?

On Sun, Oct 23, 2016 at 9:03 AM, David Dejaeghere <
david.dejaegh...@gmail.com> wrote:

> Does somebody have an idea how to replace our certificates when the new
> ROOT ca certificate has a different subject?
> The UI is down because of this.
>
> 2016-10-19 11:42 GMT+02:00 David Dejaeghere :
>
>> Hello,
>>
>> When installing FreeIPA we used the CA from our Windows servers.
>> This one recently expired and we created a new one.  It seems that the
>> new root CA has another subject name and this seems to be an issue when we
>> want to install new certs on our FreeIPA hosts.
>>
>> ipa-cacert-manage install certnew.pem -n mycert -t C,,
>>
>> Installing CA certificate, please wait
>> Failed to install the certificate: subject public key info mismatch
>>
>> After validating the subjects are indeed different.
>>
>> How can we replace the required certs for dirsrv and http when the ca is
>> not installable?
>>
>> Kind Regards,
>>
>> David
>>
>>
>>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fil Di Noto]

Hello,



I would like to better understand why IPA requires SAN (subject alternative
name) entries to have a backing host record. In order to sign a certificate
with a SAN that corresponded to a user friendly CNAME I had to add a host
record (ipa host) for that DNS name (use force option to create without an
A/ record) as well as a service principle.



I'm sure I'm not alone when I say I don't like doing that because it means
that a "Host" in FreeIPA is not a computer, it's a host record that may or
may not be the only record that corresponds to a computer. It gets
confusing.



I assume things are this way to ensure integrity at some level. But I can't
picture it. What is the potential danger of simply bypassing the
host/principal checks and just signing the certificate with whatever SAN
field we like?



If this actually is a necessity and is not likely to change, I think it
would be beneficial to administrators to be able to manage "Hosts" that
correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
are actually enrolled computers. They could be managed in a similar fashion
to SUDO rules, like maybe:



Alias Hosts = a single name

Alias Host Groups = groups of names

Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups



I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
(and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
under policy.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] PWM password self-service integration with FreeIPA

[Elwell, Jason]

I posted this on the PWM boards, and figured I'd send this along here,
too.  I'm looking for feedback on this.  Let me know if you find this
accurate and/or valuable.  Thanks!


PWM setup for FreeIPA
https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e678a

PwmConfiguration-template.xml
https://gist.github.com/PowerWagon/0e83a0c5b67316a6987944b76eb103bc
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-cacert-manage install failing with subject public key info mismatch

[David Dejaeghere]

Does somebody have an idea how to replace our certificates when the new
ROOT ca certificate has a different subject?
The UI is down because of this.

2016-10-19 11:42 GMT+02:00 David Dejaeghere :

> Hello,
>
> When installing FreeIPA we used the CA from our Windows servers.
> This one recently expired and we created a new one.  It seems that the new
> root CA has another subject name and this seems to be an issue when we want
> to install new certs on our FreeIPA hosts.
>
> ipa-cacert-manage install certnew.pem -n mycert -t C,,
>
> Installing CA certificate, please wait
> Failed to install the certificate: subject public key info mismatch
>
> After validating the subjects are indeed different.
>
> How can we replace the required certs for dirsrv and http when the ca is
> not installable?
>
> Kind Regards,
>
> David
>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Replica Problem (Errors)

[Günther J . Niederwimmer]

Hello,

I have added on my ipa (Master) Server this user and ACI with a ldif file

ldapmodify -x -D 'cn=Directory Manager' -W
dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: system
userPassword: secret123
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0

^D

dn: cn=users,cn=accounts,dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr="mailAlternateAddress")  
(targetfilter="(objectClass=mailrecipient)")
  (version
  3.0; acl "Allow system account to read mail address"; allow(read,
  search, compare) userdn =
  "ldap:///uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com;;)

This Ends with a 
modifying entry "cn=users,cn=accounts,dc=example,dc=com"

but now I have on the changed master this 100... Errors

[23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 396504 (rc: 32)
[23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 396505 (rc: 32)
[23/Oct/2016:13:27:58 +0200] DSRetroclPlugin - delete_changerecord: could not 
delete change record 396506 (rc: 32)
[23/Oct/2016:13:37:08 +0200] NSMMReplicationPlugin - replication keep alive 
entry