> 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
I can reproduce the issue with your CSR but I don't know yet what
python-cryptography doesn't like about it.
Older versions of python-cryptography yield different errors but the
issue is still elusive. I'm looking at the ASN1 encoding.
What version of certmonger is installed on the machine 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,
Hi Rob,
Here’s the content of the CSR:
-BEGIN NEW CERTIFICATE REQUEST-
MIIDjTCCAnUCAQAwIjEgMB4GA1UEAxMXbGluMDEuaXhicnUuaXBuZXhpYS5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5co5U1FjtghUjNCUIwWBO
+5b5cPGOR8Z3n6+MrUFmawrJmSS0MBkZJMRfxE2MQnNTm8zo0ASTQr2fyFqOLqdV
Djerk Geurts via FreeIPA-users wrote:
> Hi,
>
> A month or so ago we upgraded from Fedora 37 to 39. I guess this is the
> first time I’m getting round to requesting a new certificate, and it’s
> failing from a server we use to manage several certificates for non-IPA
> client hosts.
>
> Output of
Hi,
A month or so ago we upgraded from Fedora 37 to 39. I guess this is the first
time I’m getting round to requesting a new certificate, and it’s failing from a
server we use to manage several certificates for non-IPA client hosts.
Output of ipa-getcert list:
Request ID '20240402190326':
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
Antoine Gatineau via FreeIPA-users wrote:
> Hello Rob,
>
> Thank you for replying quickly.
>
> As far as I could see, the apache config is good.
> All the 'ipa cert-*' and 'ipa ca-*' were working properly.
>
> This only command not working was ipa-acme-manage (and the certbot renew
>
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
hi,
On Tue, Mar 26, 2024 at 2:47 PM Natxo Asenjo wrote:
> hi,
>
> posting back to the list.
>
> Apparently the idm server cannot find a SID of a domain when trying to
> resolve the user account. It does find the user account, but there are
> sids coupled to the account correspondig to a
Hello Rob,
Thank you for replying quickly.
As far as I could see, the apache config is good.
All the 'ipa cert-*' and 'ipa ca-*' were working properly.
This only command not working was ipa-acme-manage (and the certbot renew
obviously).
I tried adding a replica and acme was available and
14 matches
Mail list logo