Back to bug 1318616
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Petr Vobornik | 2016-03-24 19:58:16 UTC | CC | jcholast | |
| Flags | needinfo?(jcholast) | |||
| Petr Vobornik | 2016-04-08 08:36:48 UTC | Status | NEW | ASSIGNED |
| Jan Cholasta | 2016-04-11 06:26:46 UTC | Flags | needinfo?(jcholast) | |
| Petr Vobornik | 2016-04-11 08:58:11 UTC | Depends On | 1325756 | |
| Aneta Šteflová Petrová | 2016-08-25 13:30:54 UTC | Docs Contact | apetrova | |
| Flags | needinfo?(pvoborni) | |||
| Aneta Šteflová Petrová | 2016-08-25 13:31:25 UTC | Doc Type | Bug Fix | Known Issue |
| Petr Vobornik | 2016-08-25 14:42:04 UTC | Flags | needinfo?(jcholast) | |
| Petr Vobornik | 2016-08-29 11:10:58 UTC | Flags | needinfo?(pvoborni) needinfo?(jcholast) | |
| Petr Vobornik | 2016-08-29 14:52:29 UTC | Doc Text | Cause: Certificate Server by default has harder requirements for the external CA cert which is imported during ipa-ca-install. Basically it misses on trust flag set. Consequence: Certificate server will not start. ipa-ca-install will fail almost at end. (two subsequent steps won't be done). After this installation, when starting Certificate server(e.g. when starting IPA) CS won't pass self-check so it won't start an IPA won't start. Workaround (if any): Lower the requirements. Set ca.cert.signing.certusage=AnyCA in CS.cfg after running ipa-ca-install Result: Certificate server will be able to start. IPA will be able to start. |
|
| Namita Soman | 2016-08-29 15:31:14 UTC | CC | nsoman | |
| Aneta Šteflová Petrová | 2016-08-30 14:00:53 UTC | Doc Text | Cause: Certificate Server by default has harder requirements for the external CA cert which is imported during ipa-ca-install. Basically it misses on trust flag set. Consequence: Certificate server will not start. ipa-ca-install will fail almost at end. (two subsequent steps won't be done). After this installation, when starting Certificate server(e.g. when starting IPA) CS won't pass self-check so it won't start an IPA won't start. Workaround (if any): Lower the requirements. Set ca.cert.signing.certusage=AnyCA in CS.cfg after running ipa-ca-install Result: Certificate server will be able to start. IPA will be able to start. | CA fails to start after running "ipa-ca-install --external-ca" When using the "ipa-ca-install --external-ca" command to convert an IdM server without a certificate authority (CA) to a server with an integrated IdM CA, the CA does not start, which also prevents the IdM server from starting. This problem occurs because the Certificate Server has more strict requirements for the external CA certificate that is imported when running "ipa-ca-install --external-ca". As a workaround, lower these requirements by setting the following option in the `/etc/pki/pki-tomcat/ca/CS.cfg` file after running the command: ca.cert.signing.certusage=AnyCA As a result, the Certificate Server and the IdM server start as expected. |
| Flags | needinfo?(pvoborni) | |||
| Tomas Krizek | 2016-09-01 12:38:18 UTC | CC | tkrizek | |
| Petr Vobornik | 2016-09-05 17:25:31 UTC | Flags | needinfo?(pvoborni) | |
| Aneta Šteflová Petrová | 2016-09-07 11:26:31 UTC | Flags | needinfo?(pvoborni) | |
| Endi Sukma Dewata | 2016-09-08 13:54:03 UTC | CC | edewata | |
| Tomas Krizek | 2016-09-13 08:43:48 UTC | Doc Text | CA fails to start after running "ipa-ca-install --external-ca" When using the "ipa-ca-install --external-ca" command to convert an IdM server without a certificate authority (CA) to a server with an integrated IdM CA, the CA does not start, which also prevents the IdM server from starting. This problem occurs because the Certificate Server has more strict requirements for the external CA certificate that is imported when running "ipa-ca-install --external-ca". As a workaround, lower these requirements by setting the following option in the `/etc/pki/pki-tomcat/ca/CS.cfg` file after running the command: ca.cert.signing.certusage=AnyCA As a result, the Certificate Server and the IdM server start as expected. | Cause: Using a previously installed 3rd party certificate to sign the CSR generated during the CA installation with external CA. Consequence: The 3rd party certificate trust flags in NSSDB are reset and the certificate is no longer marked as trusted. Checks performed by mod_nss fail and the httpd.service fails to start. Workaround: Reset the 3rd party certificate flags to their previous state and restart httpd.service. For example, if the nickname of the certificate is ca1 and it previously had C,, trust flags, the following commands fix the issue. # certutil -d /etc/httpd/alias -n 'ca1' -M -t C,, # systemctl restart httpd.service Result: The workaround restores the system to the correct state. |
| Aneta Šteflová Petrová | 2016-09-13 09:07:18 UTC | Doc Text | Cause: Using a previously installed 3rd party certificate to sign the CSR generated during the CA installation with external CA. Consequence: The 3rd party certificate trust flags in NSSDB are reset and the certificate is no longer marked as trusted. Checks performed by mod_nss fail and the httpd.service fails to start. Workaround: Reset the 3rd party certificate flags to their previous state and restart httpd.service. For example, if the nickname of the certificate is ca1 and it previously had C,, trust flags, the following commands fix the issue. # certutil -d /etc/httpd/alias -n 'ca1' -M -t C,, # systemctl restart httpd.service Result: The workaround restores the system to the correct state. | Third-party certificate trust flags are reset after submitting a CSR to an external CA for signing The "ipa-ca-install --external-ca" command, used to install an external certificate authority (CA) into an existing Identity Management (IdM) domain, generates a certificate signing request (CSR) that the user must submit to the external CA. When using a previously installed third-party certificate to sign the CSR, the third-party certificate trust flags in the NSS database are reset. Consequently, the certificate is no longer marked as trusted. In addition, checks performed by the mod_nss module fail, and the httpd.service fails to start. As a workaround, after running the "ipa-ca-install --external-ca" command, reset the third-party certificate flags to their previous state and restart httpd.service. For example, if the `ca1` certificate previously had the `C,,` trust flags: # certutil -d /etc/httpd/alias -n 'ca1' -M -t C,, # systemctl restart httpd.service |
| Flags | needinfo?(tkrizek) | |||
| Aneta Šteflová Petrová | 2016-09-13 10:05:03 UTC | Doc Text | Third-party certificate trust flags are reset after submitting a CSR to an external CA for signing The "ipa-ca-install --external-ca" command, used to install an external certificate authority (CA) into an existing Identity Management (IdM) domain, generates a certificate signing request (CSR) that the user must submit to the external CA. When using a previously installed third-party certificate to sign the CSR, the third-party certificate trust flags in the NSS database are reset. Consequently, the certificate is no longer marked as trusted. In addition, checks performed by the mod_nss module fail, and the httpd.service fails to start. As a workaround, after running the "ipa-ca-install --external-ca" command, reset the third-party certificate flags to their previous state and restart httpd.service. For example, if the `ca1` certificate previously had the `C,,` trust flags: # certutil -d /etc/httpd/alias -n 'ca1' -M -t C,, # systemctl restart httpd.service | Third-party certificate trust flags are reset after installing an external CA into IdM The "ipa-ca-install --external-ca" command, used to install an external certificate authority (CA) into an existing Identity Management (IdM) domain, generates a certificate signing request (CSR) that the user must submit to the external CA. When using a previously installed third-party certificate to sign the CSR, the third-party certificate trust flags in the NSS database are reset. Consequently, the certificate is no longer marked as trusted. In addition, checks performed by the mod_nss module fail, and the httpd.service fails to start. The CA installation fails with the following message in this situation: CA failed to start after 300 seconds As a workaround, after this message appears, reset the third-party certificate flags to their previous state and restart httpd.service. For example, if the `ca1` certificate previously had the `C,,` trust flags: # certutil -d /etc/httpd/alias -n 'ca1' -M -t C,, # systemctl restart httpd.service This restores the system to the correct state. |
| Aneta Šteflová Petrová | 2016-09-13 10:10:07 UTC | Flags | needinfo?(pvoborni) needinfo?(tkrizek) | |
| Martin Bašti | 2016-09-19 15:59:40 UTC | Status | ASSIGNED | POST |
| CC | mbasti | |||
| Aneta Šteflová Petrová | 2016-09-26 12:29:49 UTC | Doc Text | Third-party certificate trust flags are reset after installing an external CA into IdM The "ipa-ca-install --external-ca" command, used to install an external certificate authority (CA) into an existing Identity Management (IdM) domain, generates a certificate signing request (CSR) that the user must submit to the external CA. When using a previously installed third-party certificate to sign the CSR, the third-party certificate trust flags in the NSS database are reset. Consequently, the certificate is no longer marked as trusted. In addition, checks performed by the mod_nss module fail, and the httpd.service fails to start. The CA installation fails with the following message in this situation: CA failed to start after 300 seconds As a workaround, after this message appears, reset the third-party certificate flags to their previous state and restart httpd.service. For example, if the `ca1` certificate previously had the `C,,` trust flags: # certutil -d /etc/httpd/alias -n 'ca1' -M -t C,, # systemctl restart httpd.service This restores the system to the correct state. | Third-party certificate trust flags are reset after installing an external CA into IdM The "ipa-ca-install --external-ca" command, used to install an external certificate authority (CA) into an existing Identity Management (IdM) domain, generates a certificate signing request (CSR) that the user must submit to the external CA. When using a previously installed third-party certificate to sign the CSR, the third-party certificate trust flags in the NSS database are reset. Consequently, the certificate is no longer marked as trusted. In addition, checks performed by the `mod_nss` module fail, and the *httpd* service fails to start. The CA installation fails with the following message in this situation: CA failed to start after 300 seconds As a workaround, after this message appears, reset the third-party certificate flags to their previous state and restart *httpd*. For example, if the `ca1` certificate previously had the `C,,` trust flags: # certutil -d /etc/httpd/alias -n 'ca1' -M -t C,, # systemctl restart httpd.service This restores the system to the correct state. |
| Siddharth Nagar | 2016-10-26 14:16:21 UTC | Priority | unspecified | high |
| Thorsten Scherf | 2016-10-27 07:36:38 UTC | CC | tscherf | |
| Jaroslav Reznik | 2016-10-27 09:35:07 UTC | Blocks | 1389249 | |
| Jaroslav Reznik | 2016-10-27 09:35:47 UTC | Keywords | ZStream | |
| Jan Cholasta | 2016-10-31 07:31:44 UTC | Status | POST | MODIFIED |
| Fixed In Version | ipa-4.4.0-13.el7 | |||
| errata-xmlrpc | 2017-03-01 09:32:57 UTC | Status | MODIFIED | ON_QA |
| Namita Soman | 2017-05-08 13:48:11 UTC | QA Contact | ksiddiqu | mreznik |
| Namita Soman | 2017-05-08 18:02:36 UTC | CC | ipa-qe | |
| Kaleem | 2017-05-18 05:33:14 UTC | Status | ON_QA | VERIFIED |
| CC | ksiddiqu | |||
| errata-xmlrpc | 2017-08-01 09:37:23 UTC | Status | VERIFIED | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2017-08-01 05:37:23 UTC |
Back to bug 1318616