<feed xmlns='http://www.w3.org/2005/Atom'>
<title>freeipa.git/ipalib, branch fix_ber_scanf</title>
<subtitle>FreeIPA patches</subtitle>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/'/>
<entry>
<title>Replace replication_wait_timeout with certmonger_wait_timeout</title>
<updated>2019-09-04T12:52:14+00:00</updated>
<author>
<name>Rob Crittenden</name>
<email>rcritten@redhat.com</email>
</author>
<published>2019-07-05T17:31:32+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=faf34fcdfd78208726e3e8586186f34e7c44d732'/>
<id>faf34fcdfd78208726e3e8586186f34e7c44d732</id>
<content type='text'>
The variable is intended to control the timeout for replication
events. If someone had significantly reduced it via configuration
then it could have caused certmogner requests to fail due to timeouts.

Add replication_wait_timeout, certmonger_wait_timeout and
http_timeout to the default.conf man page.

Related: https://pagure.io/freeipa/issue/7971
Reviewed-By: Florence Blanc-Renaud &lt;flo@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The variable is intended to control the timeout for replication
events. If someone had significantly reduced it via configuration
then it could have caused certmogner requests to fail due to timeouts.

Add replication_wait_timeout, certmonger_wait_timeout and
http_timeout to the default.conf man page.

Related: https://pagure.io/freeipa/issue/7971
Reviewed-By: Florence Blanc-Renaud &lt;flo@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Update comments to explain caSubsystemCert switch</title>
<updated>2019-08-08T07:46:10+00:00</updated>
<author>
<name>Christian Heimes</name>
<email>cheimes@redhat.com</email>
</author>
<published>2019-08-08T05:08:58+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=3c82585e52c9cdcf6317bbc029935f8e339bffc6'/>
<id>3c82585e52c9cdcf6317bbc029935f8e339bffc6</id>
<content type='text'>
Related: https://bugzilla.redhat.com/1670239
Signed-off-by: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Fraser Tweedale &lt;ftweedal@redhat.com&gt;
Reviewed-By: Christian Heimes &lt;cheimes@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Related: https://bugzilla.redhat.com/1670239
Signed-off-by: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Fraser Tweedale &lt;ftweedal@redhat.com&gt;
Reviewed-By: Christian Heimes &lt;cheimes@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Change RA agent certificate profile to caSubsystemCert</title>
<updated>2019-08-08T07:46:10+00:00</updated>
<author>
<name>Alexander Bokovoy</name>
<email>abokovoy@redhat.com</email>
</author>
<published>2019-08-05T14:22:44+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=802a54bfc8b698ca962b383beb3684a4b1af1865'/>
<id>802a54bfc8b698ca962b383beb3684a4b1af1865</id>
<content type='text'>
Currently, RA agent certificate is issued using caServerCert profile.
This has unfortunate side effect of asserting id-pk-serverAuth EKU which
is not really needed for RA agent. If IPA CA certificate adds SAN DNS
constraints into issued certificates, presence of id-pk-serverAuth EKU
forces NSS (and other crypto libraries) to validate CN value with
regards to SAN DNS constraints, due to historical use of CN bearing DNS
name.

Since RA agent certificate has 'CN=IPA RA', it is guaranteed to fail
the check.

Default IPA CA configuration does *not* add SAN DNS constraints into RA
agent certificate. However, it is better to be prepared to such
behavior.

Related: https://bugzilla.redhat.com/1670239
Reviewed-By: Fraser Tweedale &lt;ftweedal@redhat.com&gt;
Reviewed-By: Christian Heimes &lt;cheimes@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, RA agent certificate is issued using caServerCert profile.
This has unfortunate side effect of asserting id-pk-serverAuth EKU which
is not really needed for RA agent. If IPA CA certificate adds SAN DNS
constraints into issued certificates, presence of id-pk-serverAuth EKU
forces NSS (and other crypto libraries) to validate CN value with
regards to SAN DNS constraints, due to historical use of CN bearing DNS
name.

Since RA agent certificate has 'CN=IPA RA', it is guaranteed to fail
the check.

Default IPA CA configuration does *not* add SAN DNS constraints into RA
agent certificate. However, it is better to be prepared to such
behavior.

Related: https://bugzilla.redhat.com/1670239
Reviewed-By: Fraser Tweedale &lt;ftweedal@redhat.com&gt;
Reviewed-By: Christian Heimes &lt;cheimes@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cainstance: add profile to IPA RA tracking request</title>
<updated>2019-07-22T03:33:24+00:00</updated>
<author>
<name>Fraser Tweedale</name>
<email>ftweedal@redhat.com</email>
</author>
<published>2019-06-27T01:27:02+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=1bf008a64f15e617b0dde93555f5dca1cbdf990a'/>
<id>1bf008a64f15e617b0dde93555f5dca1cbdf990a</id>
<content type='text'>
Profile-based renewal means we should always explicitly specify the
profile in tracking requests that use the dogtag-ipa-ca-renew-agent
renewal helper.  This includes the IPA RA agent certificate.  Update
CAInstance.configure_agent_renewal() to add the profile to the
tracking request.  This also covers the upgrade scenario (because
the same method gets invoked).

Part of: https://pagure.io/freeipa/issue/7991

Reviewed-By: Rob Crittenden &lt;rcritten@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Profile-based renewal means we should always explicitly specify the
profile in tracking requests that use the dogtag-ipa-ca-renew-agent
renewal helper.  This includes the IPA RA agent certificate.  Update
CAInstance.configure_agent_renewal() to add the profile to the
tracking request.  This also covers the upgrade scenario (because
the same method gets invoked).

Part of: https://pagure.io/freeipa/issue/7991

Reviewed-By: Rob Crittenden &lt;rcritten@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>move MSCSTemplate classes to ipalib</title>
<updated>2019-07-17T14:58:58+00:00</updated>
<author>
<name>Fraser Tweedale</name>
<email>ftweedal@redhat.com</email>
</author>
<published>2019-07-11T05:17:04+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=130e1dc3433977f7a80aed139d29d21c5d30d558'/>
<id>130e1dc3433977f7a80aed139d29d21c5d30d558</id>
<content type='text'>
As we expand the integration tests for external CA functionality, it
is helpful (and avoids duplication) to use the MSCSTemplate*
classes.  These currently live in ipaserver.install.cainstance, but
ipatests is no longer permitted to import from ipaserver (see commit
81714976e5e13131654c78eb734746a20237c933).  So move these classes to
ipalib.

Part of: https://pagure.io/freeipa/issue/7548

Reviewed-By: Florence Blanc-Renaud &lt;flo@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As we expand the integration tests for external CA functionality, it
is helpful (and avoids duplication) to use the MSCSTemplate*
classes.  These currently live in ipaserver.install.cainstance, but
ipatests is no longer permitted to import from ipaserver (see commit
81714976e5e13131654c78eb734746a20237c933).  So move these classes to
ipalib.

Part of: https://pagure.io/freeipa/issue/7548

Reviewed-By: Florence Blanc-Renaud &lt;flo@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Use system-wide crypto policy for TLS ciphers</title>
<updated>2019-07-02T14:38:00+00:00</updated>
<author>
<name>Christian Heimes</name>
<email>cheimes@redhat.com</email>
</author>
<published>2019-07-02T07:49:59+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=b55344888478e2b05dc01200bed87e551aa7d00a'/>
<id>b55344888478e2b05dc01200bed87e551aa7d00a</id>
<content type='text'>
IPA now uses the system-wide crypto policy for TLS ciphers on RHEL. It's
also now possible to keep the default policy by setting TLS_HIGH_CIPHERS
to None.

Fixes: https://pagure.io/freeipa/issue/7998
Signed-off-by: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Alexander Bokovoy &lt;abokovoy@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
IPA now uses the system-wide crypto policy for TLS ciphers on RHEL. It's
also now possible to keep the default policy by setting TLS_HIGH_CIPHERS
to None.

Fixes: https://pagure.io/freeipa/issue/7998
Signed-off-by: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Alexander Bokovoy &lt;abokovoy@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Use only TLS 1.2 by default</title>
<updated>2019-07-01T12:55:29+00:00</updated>
<author>
<name>Christian Heimes</name>
<email>cheimes@redhat.com</email>
</author>
<published>2019-07-01T08:41:23+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=b57c818fab3bb9627a8c287766cdb5bd8071c837'/>
<id>b57c818fab3bb9627a8c287766cdb5bd8071c837</id>
<content type='text'>
TLS 1.3 is causing some trouble with client cert authentication.
Conditional client cert authentication requires post-handshake
authentication extension on TLS 1.3. The new feature is not fully
implemented yet.

TLS 1.0 and 1.1 are no longer state of the art and now disabled by
default.

TLS 1.2 works everywhere and supports PFS.

Related: https://pagure.io/freeipa/issue/7667

Signed-off-by: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Rob Crittenden &lt;rcritten@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
TLS 1.3 is causing some trouble with client cert authentication.
Conditional client cert authentication requires post-handshake
authentication extension on TLS 1.3. The new feature is not fully
implemented yet.

TLS 1.0 and 1.1 are no longer state of the art and now disabled by
default.

TLS 1.2 works everywhere and supports PFS.

Related: https://pagure.io/freeipa/issue/7667

Signed-off-by: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Rob Crittenden &lt;rcritten@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dnsrecord-mod: allow to modify ttl without passing the record</title>
<updated>2019-07-01T07:16:21+00:00</updated>
<author>
<name>Florence Blanc-Renaud</name>
<email>flo@redhat.com</email>
</author>
<published>2019-06-18T13:43:46+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=bb91fcabee352fcaa71c8e66998a25e01cfaf9f7'/>
<id>bb91fcabee352fcaa71c8e66998a25e01cfaf9f7</id>
<content type='text'>
The command
ipa dnsrecord-mod &lt;zone&gt; &lt;record&gt; --ttl
requires to provide at least one record to modify. When none
is specified, it prompts by proposing each of the existing records,
for instance:
ipa dnsrecord-mod ZZZZZ.org ns11 --ttl=86400
No option to modify specific record provided.
Current DNS record contents:

A record: xxx.xxx.xxx.xxx
AAAA record: xxxx:xx

Modify A record 'xxxx.xxxx.xxxx.xxxx'? Yes/No (default No):
Modify AAAA record 'xxxx:xx'? Yes/No (default No):
ipa: ERROR: No options to modify a specific record provided.

The admin should be able to modify the TTL value without
re-entering the record information. The issue happens because of an
internal check that forgot to consider 'dnsttl' as a valid standalone
modification.

Fixes: https://pagure.io/freeipa/issue/7982
Reviewed-By: Rob Crittenden &lt;rcritten@redhat.com&gt;
Reviewed-By: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Alexander Bokovoy &lt;abokovoy@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The command
ipa dnsrecord-mod &lt;zone&gt; &lt;record&gt; --ttl
requires to provide at least one record to modify. When none
is specified, it prompts by proposing each of the existing records,
for instance:
ipa dnsrecord-mod ZZZZZ.org ns11 --ttl=86400
No option to modify specific record provided.
Current DNS record contents:

A record: xxx.xxx.xxx.xxx
AAAA record: xxxx:xx

Modify A record 'xxxx.xxxx.xxxx.xxxx'? Yes/No (default No):
Modify AAAA record 'xxxx:xx'? Yes/No (default No):
ipa: ERROR: No options to modify a specific record provided.

The admin should be able to modify the TTL value without
re-entering the record information. The issue happens because of an
internal check that forgot to consider 'dnsttl' as a valid standalone
modification.

Fixes: https://pagure.io/freeipa/issue/7982
Reviewed-By: Rob Crittenden &lt;rcritten@redhat.com&gt;
Reviewed-By: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Alexander Bokovoy &lt;abokovoy@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Handle missing LWCA certificate or chain</title>
<updated>2019-06-18T00:36:24+00:00</updated>
<author>
<name>Fraser Tweedale</name>
<email>ftweedal@redhat.com</email>
</author>
<published>2019-05-30T10:57:10+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=854d3053e294e775fac0e4e394ca3b7b71d04c7d'/>
<id>854d3053e294e775fac0e4e394ca3b7b71d04c7d</id>
<content type='text'>
If lightweight CA key replication has not completed, requests for
the certificate or chain will return 404**.  This can occur in
normal operation, and should be a temporary condition.  Detect this
case and handle it by simply omitting the 'certificate' and/or
'certificate_out' fields in the response, and add a warning message
to the response.

Also update the client-side plugin that handles the
--certificate-out option.  Because the CLI will automatically print
the warning message, if the expected field is missing from the
response, just ignore it and continue processing.

** after the Dogtag NullPointerException gets fixed!

Part of: https://pagure.io/freeipa/issue/7964

Reviewed-By: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Fraser Tweedale &lt;ftweedal@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If lightweight CA key replication has not completed, requests for
the certificate or chain will return 404**.  This can occur in
normal operation, and should be a temporary condition.  Detect this
case and handle it by simply omitting the 'certificate' and/or
'certificate_out' fields in the response, and add a warning message
to the response.

Also update the client-side plugin that handles the
--certificate-out option.  Because the CLI will automatically print
the warning message, if the expected field is missing from the
response, just ignore it and continue processing.

** after the Dogtag NullPointerException gets fixed!

Part of: https://pagure.io/freeipa/issue/7964

Reviewed-By: Christian Heimes &lt;cheimes@redhat.com&gt;
Reviewed-By: Fraser Tweedale &lt;ftweedal@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>constants: add ca_renewal container</title>
<updated>2019-05-29T02:49:27+00:00</updated>
<author>
<name>Fraser Tweedale</name>
<email>ftweedal@redhat.com</email>
</author>
<published>2019-03-26T08:43:25+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/simo/public_git/freeipa.git/commit/?id=a3becc76dd22b3f26442261f163824264e7b8425'/>
<id>a3becc76dd22b3f26442261f163824264e7b8425</id>
<content type='text'>
Part of: https://pagure.io/freeipa/issue/7885

Reviewed-By: Florence Blanc-Renaud &lt;flo@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Part of: https://pagure.io/freeipa/issue/7885

Reviewed-By: Florence Blanc-Renaud &lt;flo@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
