I take that back. Replication is working on 4/6 servers.
If I add a user on any of those 4 it shows up on the other 3. The 2 outliers
don't seem to pick up the new user. If I check the 2 outliers I get this
Error (18) Replication error acquiring replica: Incremental update transient
error.
I tried adding a test user on one of the servers that returned that warning and
the new user didn't appear on the others.
So maybe replication is broken.
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an
Alright, so 'ipa idrange-find' returns the same values on all 6 servers.
However, ldapsearch -x -D 'cn=Directory Manager' -W -b 'cn=Posix
IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config'
returns different results on 1 (the one where I don't get that warning with the
Travis West via FreeIPA-users wrote:
> Thanks Rob! New certs are all replicated and all IPA services are started on
> all 6 servers.
> I can perform 'ipa cert-show 1' on all 6 and get the expected result.
>
> As a sanity check I did run the ipa-healthcheck on all 6 servers. One of
> them came
Thanks Rob! New certs are all replicated and all IPA services are started on
all 6 servers.
I can perform 'ipa cert-show 1' on all 6 and get the expected result.
As a sanity check I did run the ipa-healthcheck on all 6 servers. One of them
came back fine, the other 5 returned
[
{
Travis West via FreeIPA-users wrote:
> The problem was definitely the ra-agent.pem. I generated a new one and
> imported it to ~/.dogtag/nssdb, LDAP and placed the pem and key in
> /var/lib/ipa/
>
> Now I can verify the certificate with the openssl verify command.
> Additionally the error in
The problem was definitely the ra-agent.pem. I generated a new one and
imported it to ~/.dogtag/nssdb, LDAP and placed the pem and key in /var/lib/ipa/
Now I can verify the certificate with the openssl verify command. Additionally
the error in the UI is gone and running an 'ipa cert-show 1'
This morning I thought I had found what I was missing, import the new RA cert
to ~/.dogtag/nssdb, which I've done and now all the places I know about the RA
cert matches.
# certutil -L -d /root/.dogtag/nssdb
Certificate Nickname Trust Attributes
I spun up a new server and did a fresh install of IPA. On that server if I run
the command I get a better result
# openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt
/var/lib/ipa/ra-agent.pem
/var/lib/ipa/ra-agent.pem: OK
Chain:
depth=0: O = AUTH..NET, CN = IPA RA (untrusted)
If I run that command manually it doesn't appear to do anything except output
'recognized usages"
If I try it without the -show_chain flag I get
# openssl verify -verbose -CAfile /etc/ipa/ca.crt /var/lib/ipa/ra-agent.pem
/var/lib/ipa/ra-agent.pem: O = IPA..NET, CN = IPA RA
error 20 at 0
Travis West via FreeIPA-users wrote:
> Rob,
>
> I installed the ipa-healthcheck that you got to work on CentOS 7, and run it.
> Got a couple of errors regarding the RA Agent cert:
>
> [
> {
> "source": "ipahealthcheck.ipa.certs",
> "kw": {
> "msg": "Certificate validation for
Rob,
I installed the ipa-healthcheck that you got to work on CentOS 7, and run it.
Got a couple of errors regarding the RA Agent cert:
[
{
"source": "ipahealthcheck.ipa.certs",
"kw": {
"msg": "Certificate validation for /var/lib/ipa/ra-agent.pem failed: ",
"reason": "",
This morning I tried running ipa-server-upgrade to see if that would help. It
ultimately failed, but in a different spot and with a different error:
2024-04-04T11:36:42Z DEBUG The CA status is: running
2024-04-04T11:36:42Z INFO [Ensuring CA is using LDAPProfileSubsystem]
2024-04-04T11:36:42Z
Here is the output of validation
# certutil -V -u V -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -e
-f /etc/pki/pki-tomcat/alias/pwdfile.txt
certutil: certificate is valid
And for the asn.1 of the Audit, OCSP, Subsystem, and RA certs
$ openssl asn1parse -inform pem -in audit.crt
Travis West via FreeIPA-users wrote:
> In the apache error log I found this that is generated when, in the UI, I try
> to access Authentication > Certificates > Certificate Authorities.
>
> [Wed Apr 03 16:33:28.439180 2024] [:error] [pid 19048] ipa: INFO:
> [jsonserver_session]
In the apache error log I found this that is generated when, in the UI, I try
to access Authentication > Certificates > Certificate Authorities.
[Wed Apr 03 16:33:28.439180 2024] [:error] [pid 19048] ipa: INFO:
[jsonserver_session] twest@IPA..NET: cert_find(None, version=u'2.230'):
No I didn't go back in time, I generated new certificates and imported them to
NSS DB after deleting the ones that contained Principles that had other hosts
listed.
I then updated the CS.cfg with the cert and certreq values, and made sure the
CA Subsystem cert in NSS DB matched what is in
Travis West via FreeIPA-users wrote:
> Spoke too soon. If I try to get a new certificate on an enrolled host I get
> this
>
> status: CA_UNREACHABLE
> ca-error: Server at https://ipa1-sea2.ipa..net/ipa/xml failed request,
> will retry: 907 (RPC failed at server. cannot connect to
>
Spoke too soon. If I try to get a new certificate on an enrolled host I get
this
status: CA_UNREACHABLE
ca-error: Server at https://ipa1-sea2.ipa..net/ipa/xml failed request, will
retry: 907 (RPC failed at server. cannot connect to
Swapping the O and CN in the req did the trick for the getcert list output
Request ID '20190322032031':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin set
> On Wed, Apr 3, 2024 at 5:24 AM Travis West via FreeIPA-users <
> freeipa-users(a)lists.fedorahosted.org wrote:
>
> That's exactly my point. I would expect subject and issuer to display the
> components in the same order (ending with O=IPA..NET). The subject was
> provided to openssl req
On Wed, Apr 3, 2024 at 5:24 AM Travis West via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:
> > Hi,
> >
> > On Tue, Apr 2, 2024 at 8:50 PM Travis West via FreeIPA-users <
> > freeipa-users(a)lists.fedorahosted.org wrote:
> >
> > As Rob wrote, it's not a problem that getcert list,
> Hi,
>
> On Tue, Apr 2, 2024 at 8:50 PM Travis West via FreeIPA-users <
> freeipa-users(a)lists.fedorahosted.org wrote:
>
> As Rob wrote, it's not a problem that getcert list, OpenssL and NSS
> libraries show the subject in a DN order (RFC2253) or DN reverse order, but
> I find it suspect that
Hi,
On Tue, Apr 2, 2024 at 8:50 PM Travis West via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:
> Okay, I've generated new certs that don't have the extra space. Once
> those were imported to the NSS DB I also updated the CS.cfg with the new
> cert and certreq vaules for OCSP,
Okay, I've generated new certs that don't have the extra space. Once those
were imported to the NSS DB I also updated the CS.cfg with the new cert and
certreq vaules for OCSP, Audit, and Subsystem.
I also did an ldapsearch for the Subsystem certificate to make sure it matches.
I then tried to
This was the command I used to generate the CSRs
openssl req -new -sha256 -key subsystem.key -subj "/CN=CA Subsystem
/O=IPA..NET" -out subsystem.csr
But I guess that results in the extra space. So perhaps it should be
openssl req -new -sha256 -key subsystem.key -subj "/CN=CA
Travis West via FreeIPA-users wrote:
> Okay, I've sort of fixed the tracking, but there is still an issue I can't
> seem to solve. Here is the tracking now for the Audit, OCSP, and Subsystem
> certificates
>
> Number of certificates and requests being tracked: 9.
> Request ID '20190322032029':
Okay, I've sort of fixed the tracking, but there is still an issue I can't seem
to solve. Here is the tracking now for the Audit, OCSP, and Subsystem
certificates
Number of certificates and requests being tracked: 9.
Request ID '20190322032029':
status: MONITORING
stuck: no
I noticed some issues with the newly generated certs in my previous update. I
have again generated new certs that this time have the Subject correct.
I can delete the bad certs that contain errant Principal from
/etc/pki/pki-tomcat/alias and import the new ones. Then update the CA
Subsystem
Over the weekend I was able to find the CA cert and matching key. So I was
able to generate a new certificate using these have them signed correctly.
Here is how I did that (subsystem cert as an example)
CSR gen
openssl req -new -sha256 -key subsystem.key -subj "/CN=CA Subsystem
Travis West via FreeIPA-users wrote:
> I've just found an old p12 file from 2019. I was able to extract the key
> from that and it does match the CA Subystem cert that expired 8 March that is
> listed in LDAP.
> So if I could somehow generate a new certificate with this and import into
> the
I've just found an old p12 file from 2019. I was able to extract the key from
that and it does match the CA Subystem cert that expired 8 March that is listed
in LDAP.
So if I could somehow generate a new certificate with this and import into the
NSS DB for /etc/pki/pki-tomcat/alias would that
Hm, it looks like on one of the IPA servers I have a copy of
/etc/pki/pki-tomcat/alias from 2019. I'm not sure if I can use this somehow to
get back to normal by restoring then setting the time back and trying to renew
the certs.
I guess I don't know for sure if this has the correctly named
Rob,
I did manage to find valid .p12 files for ocsp and ca subsystem with an expiry
date of 2019. Is there any way to recover this installation by inserting these?
Alternatively is there a way to delete these errant certs from the NSS DB in
/etc/pki/pki-tomcat/alias and get new ones issued
Travis West via FreeIPA-users wrote:
> I've restored the Renewal Master from before I started changing this. If I
> run getcert list I do see 9 certificates being tracked.
> None of the system certs seem to expire at the same time, but they also all
> have incorrect Common Name in the Subject.
I've restored the Renewal Master from before I started changing this. If I run
getcert list I do see 9 certificates being tracked.
None of the system certs seem to expire at the same time, but they also all
have incorrect Common Name in the Subject. The RA cert is also expired and has
an
Yes, running on CentOS 7.9. Just for testing sake I did update one of the
servers to a later version of IPA that has ipa-cert-fix, and tried running it,
it returned this (CN partially censored)
# ipa-cert-fix
The following certificates will be renewed:
Dogtag subsystem certificate:
Travis West via FreeIPA-users wrote:
> The person who set this up is no longer available. We have 6 IPA servers in
> a cluster, all set as MASTER. All servers are running IPA v. 4.6.4.
> On 8 March the CA Subsystem certificate expired. When looking at the
> certificate I noticed it had an
38 matches
Mail list logo
