Hi German,
thanks for having a look into this.
There is no customer case in the RedHat portal. We're using the upstream
FreeIPA from CentOS.
Attaching the /var/log/pki/pki-tomcat/ca/debug log. The timestamp of the
resubmission was Sat Nov 10 12:03:23 CET 2018 (time set back prior the
expiration). I don't see anything interesting from that time, though the
getcert list suggests it tried to talk to the ipa07 from which the debug
log was collected.
ca-error: Error 60 connecting to
https://ipa07.example.com:8443/ca/agent/ca/profileReview: Peer certificate
cannot be authenticated with given CA certificates.
Did not perform a full restore from backup since it would require a
re-initialization from single replica, which possesses a risk of losing
more CA replicas. However I confirmed the contents of
/etc/pki/pki-tomcat/alias are identical to other replicas, where no manual
changes were made. Can't restore the deleted CSR from o=ipaca, since I
don't have a backup of it. We have full backups (/usr/sbin/ipa-backup) of
other replica, so theoretically it should be possible to get if from there,
but we're getting the same error regardless the CSR removal. I've also
checked that
cn=EXAMPLE.COM IPA
CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com contains the latest CA
cert.
This is the output of requested commands. Same output also on a different
replica.
[root@ipa07:/] certutil -V -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert
cert-pki-ca" -u O
certutil: certificate is valid
[root@ipa07:/] certutil -V -d /etc/pki/pki-tomcat/alias -n "subsystemCert
cert-pki-ca" -u C
certutil: certificate is valid
[root@ipa07:/] certutil -V -d /etc/pki/pki-tomcat/alias -n "Server-Cert
cert-pki-ca" -u V
certutil: certificate is valid
[root@ipa07:/] certutil -V -d /etc/pki/pki-tomcat/alias -n
"auditSigningCert cert-pki-ca" -u J
certutil: certificate is valid
[root@ipa07:/] certutil -V -d /etc/pki/pki-tomcat/alias -n "caSigningCert
cert-pki-ca" -u L
certutil: certificate is valid
Thanks
Petr
On Tue, Jan 8, 2019 at 5:13 PM German Parente <gparente(a)redhat.com> wrote:
Hi Petr,
I was asked to take a look at this issue. I wanted to know if, in
parallel, there is a customer case open in redhat portal.
If not, could you provide the /var/log/pki-tomcat/ca/debug log file and
the timestamp of resubmission ?
I would not change manually the cert db's under /etc/pki/pki-tomcat/alias
not delete or recreate any object under o=ipaca, as possible. If you have
backups, please restore to original ones.
I know about issues with certificate encoding. In general, the error I use
to see is a little bit different like "error -8179:Peer's Certificate
issuer is not recognized".
It could be interesting to check your certificates in cert db once date
has been set back by doing:
certutil -V -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-ca" -u O
certutil -V -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -u C
certutil -V -d /etc/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -u V
certutil -V -d /etc/pki/pki-tomcat/alias -n "auditSigningCert cert-pki-ca" -u
J
certutil -V -d /etc/pki/pki-tomcat/alias -n "caSigningCert cert-pki-ca" -u L
that is more or less where our selftests are doing for PKI component.
Thanks and regards,
German.
On Fri, Jan 4, 2019 at 1:44 PM Petr Benas via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
> Hello,
>
> we have an issue with resubmitting several certificates.
>
> We suspect the reason might be the encoding mismatch between the
> certificate and the CA certificate.
>
> Our environment was upgraded during the years from some 3.x version to
> current 4.5.4. So the very first CA certificate was encoded in
> PRINTABLESTRING.
>
> Issuer:
> organizationName =
PRINTABLESTRING:EXAMPLE.COM
> commonName = PRINTABLESTRING:Certificate
> Authority
> Validity
> Not Before: Dec 1 14:14:37 2014 GMT
> Not After : Dec 1 14:14:37 2034 GMT
> Subject:
> organizationName =
PRINTABLESTRING:EXAMPLE.COM
> commonName = PRINTABLESTRING:Certificate
> Authority
>
> When we renew-ed (due to SHA1) we got to PRINTABLESTRING X UTF8STRING and
> after we renewed again, so now we have:
>
> Issuer:
> organizationName =
UTF8STRING:EXAMPLE.COM
> commonName = UTF8STRING:Certificate Authority
> Validity
> Not Before: Oct 9 07:34:24 2017 GMT
> Not After : Oct 9 07:34:24 2037 GMT
> Subject:
> organizationName =
UTF8STRING:EXAMPLE.COM
> commonName = UTF8STRING:Certificate Authority
>
> And most certificated were renewed fine.
>
> However, recently we noticed that several certificated can't be
> resubmitted, all of them seem to be like this:
>
> Issuer:
> organizationName =
PRINTABLESTRING:EXAMPLE.COM
> commonName = PRINTABLESTRING:Certificate
> Authority
> Validity
> Not Before: Nov 24 12:17:12 2016 GMT
> Not After : Nov 14 12:17:12 2018 GMT
> Subject:
> organizationName =
UTF8STRING:EXAMPLE.COM
> commonName =
UTF8STRING:ipa07.example.com
>
> The error when resubmitting is:
> Peer certificate cannot be authenticated with given CA certificates. The
> tcpdump from 8443 says Unknown CA.
>
> Is the assumption that the encoding mismatch is blocking the submitting
> certificate correct?
> One of the certificate which we also can't renew is the 'IPA RA'
> (/var/lib/ipa/ra-agent.pem)
>
> What we tried:
> Add all versions of CA certificate to /etc/pki/pki-tomcat/alias
> trust store (also add them one-by-one)
> Setting date back before the expiration.
> Advises from:
>
https://rcritten.wordpress.com/2017/09/20/peer-certificate-cannot-be-auth...
> Deleting the related CSR from o=ipaca, supposing that newly
> generated csr will be fine.
>
> Any suggestions what else we could try?
>
> Thanks
> Petr
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>