[Freeipa-users] How to remove bad cert renewal from certmonger?

[Tikkanen, Tuomo (Nokia - FI/Espoo)]

Hello all,

I tried to renew the server HTTP certificates for two freeipa servers so
that certs would have Subject Alternative Name (SAN) fields for all the
addresses they have (two DNS names and IPs). I won't go to the details
why this is required, but I started with ipa2 (slave) and immediately
got problems. Some I managed to solve, but there is now problem to which
I have not found any solution.

How to remove from certmonger a renewal request that has a bad
certificate request in it?

What I did was:

# ipa-getcert resubmit -i "20160212110456" -D "ipa2.lab-public-domain"
-D "ipa2.lab-management-domain" -D "10.22.199.253" -D "10.10.1.253" -A
"10.22.199.253" -A "10.10.1.253"

This led to a problem that ipa2.lab-management-domain server was not as
host in the freeipa. Added the needed info:

# ipa host-add ipa2.lab-management-domain
# ipa service-add HTTP/ipa2.lab-management-domain --force
# ipa service-add-host HTTP/lab-management-domain --host
ipa2.lab-management-domain

Then I ran the above resubmit command again.

This time the there was an error related to the -D "10.22.199.253" and
-D "10.10.1.253" fields. And because it is not possible to use ipa
host-add "10.22.199.253" I decided just to drop the -D fields with IP
addresses, but left the -A options. And ran the resubmit command again.

Now the error in ipa-getcert list command changed to tell that IP
Address is forbidden:

# ipa-getcert list -i "20160212110456"
.......
Request ID '20160212110456':
status: MONITORING
ca-error: Server at https://ipa2.lab-public-domain/ipa/xml
denied our request, giving up: 2100 (RPC failed at server. Insufficient
access: Subject alt name type IP Address is forbidden).
stuck: no
.......

That is the state where I now have stuck. I have tried the ipa-getcert
resubmit command without any -D or -A fields but the error stays there.

I took the "csr=" value from the file
/var/lib/certmonger/requests/20160212110456 and saved it to /tmp/request
file. Using openssl I can see that it still contains SAN attribute with
IP addresses and two odd fields that probably are there because of those
-D "IP" fields I had at the beginning:

# openssl req -in /tmp/request -text -noout
.........
X509v3 Subject Alternative Name:
DNS:ipa2.lab-public-domain, DNS:ipa2.lab-public-domain,
othername:<unsupported>, othername:<unsupported>, IP
Address:10.22.199.253, IP Address:10.10.1.253
.........

Repetitio est mater studiorum:

How I can clean this defective state of certmonger?


Second question if/when the above urgent problem is solved:

Is there any way to get IP address to SAN field for the IPA Server-Certs?

The system is Centos7(.2) with and freeipa is installed from the repository:

# cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)
# yum list installed | grep ipa
ipa-admintools.x86_64 4.2.0-15.el7_2.6 @updates
ipa-client.x86_64 4.2.0-15.el7_2.6 @updates
ipa-python.x86_64 4.2.0-15.el7_2.6 @updates
ipa-server.x86_64 4.2.0-15.el7_2.6 @updates
ipa-server-dns.x86_64 4.2.0-15.el7_2.6 @updates
libipa_hbac.x86_64 1.13.0-40.el7_2.1 @updates
python-iniparse.noarch 0.4-9.el7 @anaconda
python-libipa_hbac.x86_64 1.13.0-40.el7_2.1 @updates
sssd-ipa.x86_64 1.13.0-40.el7_2.1 @updates

BR,

[Rob Crittenden]

Post by Tikkanen, Tuomo (Nokia - FI/Espoo)
Hello all,
I tried to renew the server HTTP certificates for two freeipa servers so
that certs would have Subject Alternative Name (SAN) fields for all the
addresses they have (two DNS names and IPs). I won't go to the details
why this is required, but I started with ipa2 (slave) and immediately
got problems. Some I managed to solve, but there is now problem to which
I have not found any solution.
How to remove from certmonger a renewal request that has a bad
certificate request in it?
# ipa-getcert resubmit -i "20160212110456" -D "ipa2.lab-public-domain"
-D "ipa2.lab-management-domain" -D "10.22.199.253" -D "10.10.1.253" -A
"10.22.199.253" -A "10.10.1.253"
This led to a problem that ipa2.lab-management-domain server was not as
# ipa host-add ipa2.lab-management-domain
# ipa service-add HTTP/ipa2.lab-management-domain --force
# ipa service-add-host HTTP/lab-management-domain --host
ipa2.lab-management-domain
Then I ran the above resubmit command again.
This time the there was an error related to the -D "10.22.199.253" and
-D "10.10.1.253" fields. And because it is not possible to use ipa
host-add "10.22.199.253" I decided just to drop the -D fields with IP
addresses, but left the -A options. And ran the resubmit command again.
Now the error in ipa-getcert list command changed to tell that IP
# ipa-getcert list -i "20160212110456"
.......
status: MONITORING
ca-error: Server at https://ipa2.lab-public-domain/ipa/xml
denied our request, giving up: 2100 (RPC failed at server. Insufficient
access: Subject alt name type IP Address is forbidden).
stuck: no
.......
That is the state where I now have stuck. I have tried the ipa-getcert
resubmit command without any -D or -A fields but the error stays there.
I took the "csr=" value from the file
/var/lib/certmonger/requests/20160212110456 and saved it to /tmp/request
file. Using openssl I can see that it still contains SAN attribute with
IP addresses and two odd fields that probably are there because of those
# openssl req -in /tmp/request -text -noout
.........
DNS:ipa2.lab-public-domain, DNS:ipa2.lab-public-domain,
othername:<unsupported>, othername:<unsupported>, IP
Address:10.22.199.253, IP Address:10.10.1.253
.........
How I can clean this defective state of certmonger?

# ipa-getcert stop-tracking -i 20160212110456

Post by Tikkanen, Tuomo (Nokia - FI/Espoo)
Is there any way to get IP address to SAN field for the IPA Server-Certs?

Not without changing code. IP address SAN are explicitly forbidden:
Subject alt name type IP Address is forbidden

rob

[Tikkanen, Tuomo (Nokia - FI/Espoo)]

........

Post by Rob Crittenden

Post by Tikkanen, Tuomo (Nokia - FI/Espoo)
How I can clean this defective state of certmonger?

# ipa-getcert stop-tracking -i 20160212110456

Ah! That was obvious! Thanks a lot Rob.

Post by Rob Crittenden

Post by Tikkanen, Tuomo (Nokia - FI/Espoo)
Is there any way to get IP address to SAN field for the IPA Server-Certs?

Subject alt name type IP Address is forbidden
rob

Is there any true reason why IP Address is forbidden by certmonger /
freeipa? Or is it just "not implemented" kind of restriction?

[Rob Crittenden]

This post might be inappropriate. Click to display it.

[Alexander Bokovoy]

Post by Rob Crittenden

Post by Tikkanen, Tuomo (Nokia - FI/Espoo)
........

Post by Rob Crittenden

Post by Tikkanen, Tuomo (Nokia - FI/Espoo)
How I can clean this defective state of certmonger?

# ipa-getcert stop-tracking -i 20160212110456

Ah! That was obvious! Thanks a lot Rob.

Post by Rob Crittenden

Post by Tikkanen, Tuomo (Nokia - FI/Espoo)
Is there any way to get IP address to SAN field for the IPA
Server-Certs?

Subject alt name type IP Address is forbidden
rob

Is there any true reason why IP Address is forbidden by certmonger /
freeipa? Or is it just "not implemented" kind of restriction?

It is denied by IPA, not certmonger.
IP addresses are frowned upon in certs in general and they are denied
by IPA because the access control would be really difficult. Today a
host must be granted access to issue certs with additional names in
it.
You can open a RFE for this on the IPA trac if you really need it.
I'm not deeply familiar with the new profile support so perhaps it is
possible to do this using the latest version of IPA, I'm not sure.

Correct and no, it is not right now.

Certificate profile defines what CA considers possible to grant when
issuing a cert. CA doesn't have contextual logic -- that would be
provided by an agent approving the cert. IPA framework is sitting in
front of CA to put the context in place and could be considered such an
agent, so we have logic to cross-check the request for fields that would
be conflicting with IPA access controls.

As it happens now, IPA framework disallows IP addresses. Adding support
for that would need to get proper logic in place to decide which
address spaces to allow being managing by a requesting party -- a host
in your case as certmonger asks for the cert on behalf of the host. We
don't have any system in place for that.

[Tikkanen, Tuomo (Nokia - FI/Espoo)]

-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
........
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----

Post by Alexander Bokovoy

Post by Rob Crittenden
It is denied by IPA, not certmonger.
IP addresses are frowned upon in certs in general and they are denied
by IPA because the access control would be really difficult. Today a
host must be granted access to issue certs with additional names in it.
You can open a RFE for this on the IPA trac if you really need it.
I'm not deeply familiar with the new profile support so perhaps it is
possible to do this using the latest version of IPA, I'm not sure.

Correct and no, it is not right now.
Certificate profile defines what CA considers possible to grant when
issuing a cert. CA doesn't have contextual logic -- that would be
provided by an agent approving the cert. IPA framework is sitting in
front of CA to put the context in place and could be considered such an
agent, so we have logic to cross-check the request for fields that would
be conflicting with IPA access controls.
As it happens now, IPA framework disallows IP addresses. Adding support
for that would need to get proper logic in place to decide which
address spaces to allow being managing by a requesting party -- a host
in your case as certmonger asks for the cert on behalf of the host. We
don't have any system in place for that.

Because I am not an expert on IPA / cert-business I might over-simplify
the case.

To me letting to add to SAN an IP address of related FQDN would be quite
simple case. When I am requesting cert for ipa2.public.domain and
ipa2.management.domain and wanting to have also their IPs in SAN
extension of the cert. The logic would be something like; IPA framework
checks that related FQDNs and their DNS information is in place in IPA
=> allow

There probably are much more complicated cases though. I understand that
to create huge number of exceptions for all the possible cases would be
mission impossible. Thus it would be nice if there would be possibility
for ipa admin to create this kind of rules to allow local exceptions --
even frowned ones.

In my original email I promised not to go details why I'd need the
feature, but here we go...

In our case the IP in SAN would be needed because our lab has its own
DNS space that is not published to intranet side. However there are
situations when user needs / wants to connect certain web services in
lab also from intranet (to change his password on IPA for example). In
such cases he has to give URL with IP address, but browsers tell that
the certificate is invalid because the cert is only valid for FQDN.

Naturally it is possible to create an exception on browser or add
/etc/hots entry for FQDN on intranet computer. However to me IP in SAN
would be much more elegant and clean solution.

[Alexander Bokovoy]

Post by Tikkanen, Tuomo (Nokia - FI/Espoo)
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
........
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----

Post by Alexander Bokovoy

Post by Rob Crittenden
It is denied by IPA, not certmonger.
IP addresses are frowned upon in certs in general and they are denied
by IPA because the access control would be really difficult. Today a
host must be granted access to issue certs with additional names in it.
You can open a RFE for this on the IPA trac if you really need it.
I'm not deeply familiar with the new profile support so perhaps it is
possible to do this using the latest version of IPA, I'm not sure.

Correct and no, it is not right now.
Certificate profile defines what CA considers possible to grant when
issuing a cert. CA doesn't have contextual logic -- that would be
provided by an agent approving the cert. IPA framework is sitting in
front of CA to put the context in place and could be considered such an
agent, so we have logic to cross-check the request for fields that would
be conflicting with IPA access controls.
As it happens now, IPA framework disallows IP addresses. Adding support
for that would need to get proper logic in place to decide which
address spaces to allow being managing by a requesting party -- a host
in your case as certmonger asks for the cert on behalf of the host. We
don't have any system in place for that.

Because I am not an expert on IPA / cert-business I might
over-simplify the case.
To me letting to add to SAN an IP address of related FQDN would be
quite simple case. When I am requesting cert for ipa2.public.domain
and ipa2.management.domain and wanting to have also their IPs in SAN
extension of the cert. The logic would be something like; IPA
framework checks that related FQDNs and their DNS information is in
place in IPA => allow

We don't have for a general case any means to rely on the IP address <->
host name mapping. For cases where there is DNS zone managed by IPA we
might add a logic, I agree, but not in general unless there is DNSSEC in
place -- because with DNSSEC we could at least be able to verify
signatures on the records to see if we could trust the data.

Post by Tikkanen, Tuomo (Nokia - FI/Espoo)
There probably are much more complicated cases though. I understand
that to create huge number of exceptions for all the possible cases
would be mission impossible. Thus it would be nice if there would be
possibility for ipa admin to create this kind of rules to allow local
exceptions -- even frowned ones.
In my original email I promised not to go details why I'd need the
feature, but here we go...
In our case the IP in SAN would be needed because our lab has its own
DNS space that is not published to intranet side. However there are
situations when user needs / wants to connect certain web services in
lab also from intranet (to change his password on IPA for example). In
such cases he has to give URL with IP address, but browsers tell that
the certificate is invalid because the cert is only valid for FQDN.
Naturally it is possible to create an exception on browser or add
/etc/hots entry for FQDN on intranet computer. However to me IP in SAN
would be much more elegant and clean solution.

I understand you pain. You can file a ticket with a feature request for
that use case.