freeipa/certmonger for openvpn user certificates
by Patrick Spinler
Hi,
I'm setting up an openvpn server and I'd like to use our already existing FreeIPA CA to issue user keys/certs for openvpn's use. Since our OpenVPN box is a freeipa client, I thought it'd be nice to use certmonger to issue and keep up to date these certs.
Ergo, I've created a certificate profile:
pat@apex-freeipa ~$ ipa certprofile-show --all OpenVPNUserCert
dn: cn=OpenVPNUserCert,cn=certprofiles,cn=ca,dc=int,dc=apexmw,dc=com
Profile ID: OpenVPNUserCert
Profile description: OpenVPN User Certificates
Store issued certificates: FALSE
objectclass: ipacertprofile, top
And also a CA acl. For experimentation (and working vs our test freeipa) I've left this as wide open as I can:
[pat@apex-freeipa ~]$ ipa caacl-show --all OpenVPN_User_Certificate_ACL
dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com
ACL name: OpenVPN_User_Certificate_ACL
Enabled: TRUE
CA category: all
Profile category: all
User category: all
Host category: all
Service category: all
ipauniqueid: 6dde33a6-7849-11e9-aa05-525400b52c7b
objectclass: ipaassociation, ipacaacl
Then, on my openvpn server, I ask for a cert for use for one of my users (myself, in this case):
root@apex-openvpn:~# ipa-getcert request -f /etc/openvpn/client/pat.crt -k /etc/openvpn/client/pat.key -r -N 'CN=pat,O=INT.APEXMW.COM' -K pat -g 4096 --profile OpenVPNUserCert
New signing request "20190603014016" added.
But, it fails due to an access err vs the 'userCertificate' attribute of my account:
root@apex-openvpn:~# ipa-getcert list
(...snippy snip excess...)
Request ID '20190603014016':
status: CA_REJECTED
ca-error: Server at https://apex-freeipa.int.apexmw.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com'.).
stuck: yes
key pair storage: type=FILE,location='/etc/openvpn/client/pat.key'
certificate: type=FILE,location='/etc/openvpn/client/pat.crt'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
If I look at the dirsrv log, here's the accesses I see for this request (trimmed off the date/time to make the lines a _little_ shorter):
root@apex-freeipa slapd-INT-APEXMW-COM# grep conn=178 access | cut -d' ' -f3-
conn=178 fd=114 slot=114 connection from 10.10.200.1 to 10.10.200.1
conn=178 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO
conn=178 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0025554208 dn="fqdn=apex-openvpn.int.apexmw.com,cn=computers,cn=accounts,dc=int,dc=apexmw,dc=com"
conn=178 op=1 SRCH base="cn=ipaconfig,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL
conn=178 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0001319554
conn=178 op=2 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL
conn=178 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000979573
conn=178 op=3 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL
conn=178 op=3 RESULT err=0 tag=101 nentries=1 etime=0.0000736730
conn=178 op=4 SRCH base="cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaca)(cn=ipa))" attrs=""
conn=178 op=4 RESULT err=0 tag=101 nentries=1 etime=0.0000499142
conn=178 op=5 SRCH base="cn=ipa,cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="ipaCaId ipaCaSubjectDN cn ipaCaIssuerDN description"
conn=178 op=5 RESULT err=0 tag=101 nentries=1 etime=0.0000482726
conn=178 op=6 SRCH base="cn=apex-freeipa.int.apexmw.com,cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=CA))" attrs=ALL
conn=178 op=6 RESULT err=0 tag=101 nentries=1 etime=0.0000950646 notes=U
conn=178 op=7 SRCH base="cn=accounts,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=pat(a)INT.APEXMW.COM))" attrs=ALL
conn=178 op=7 RESULT err=0 tag=101 nentries=1 etime=0.0002747849
conn=178 op=8 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin"
conn=178 op=8 RESULT err=0 tag=120 nentries=0 etime=0.0000135034
conn=178 op=9 SRCH base="cn=request certificate ignore caacl,cn=virtual operations,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass"
conn=178 op=9 RESULT err=0 tag=101 nentries=1 etime=0.0000932668 - entryLevelRights: none
conn=178 op=10 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="distinguishedName"
conn=178 op=10 RESULT err=0 tag=101 nentries=1 etime=0.0000640289
conn=178 op=11 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="telephoneNumber ipaSshPubKey uid krbCanonicalName ipatokenRadiusUserName ipaUserAuthType krbPrincipalExpiration homeDirectory nsAccountLock usercertificate;binary title loginShell uidNumber mail ipaCertMapData memberOf memberofindirect krbPrincipalName givenName gidNumber sn ou userClass ipatokenRadiusConfigLink"
conn=178 op=11 RESULT err=0 tag=101 nentries=1 etime=0.0001401737
conn=178 op=12 SRCH base="dc=int,dc=apexmw,dc=com" scope=2 filter="(|(member=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com)(memberUser=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com)(memberHost=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com))" attrs=""
conn=178 op=12 RESULT err=0 tag=101 nentries=7 etime=0.0001492344 notes=P pr_idx=0 pr_cookie=-1
conn=178 op=13 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(userPassword=*)" attrs="userPassword"
conn=178 op=13 RESULT err=0 tag=101 nentries=1 etime=0.0000524838
conn=178 op=14 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey"
conn=178 op=14 RESULT err=0 tag=101 nentries=1 etime=0.0000597589
conn=178 op=15 SRCH base="ipaUniqueID=80b23b30-6a0c-11e9-baa3-525400b52c7b,cn=sudorules,cn=sudo,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="cn"
conn=178 op=15 RESULT err=0 tag=101 nentries=1 etime=0.0000379744
conn=178 op=16 SRCH base="ipaUniqueID=5fb3a640-705a-11e9-aa05-525400b52c7b,cn=hbac,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="cn"
conn=178 op=16 RESULT err=0 tag=101 nentries=1 etime=0.0000337904
conn=178 op=17 SRCH base="cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com" scope=1 filter="(&(objectClass=ipaassociation)(objectClass=ipacaacl))" attrs="serviceCategory cn ipaMemberCertProfile ipaMemberCa ipaCertProfileCategory memberUser userCategory hostCategory memberHost ipaEnabledFlag ipaCaCategory memberService description"
conn=178 op=17 RESULT err=0 tag=101 nentries=2 etime=0.0001647058
conn=178 op=18 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin"
conn=178 op=18 RESULT err=0 tag=120 nentries=0 etime=0.0000138321
conn=178 op=19 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="userCertificate"
conn=178 op=19 RESULT err=0 tag=101 nentries=1 etime=0.0001475052 - entryLevelRights: none
conn=178 op=20 UNBIND
conn=178 op=20 fd=114 closed - U1
To begin with, I note that this session does a BIND with 'dn=""', right at the beginning, it's essentially an anonymous bind, yah?
That operation near the end, here:
op=17 SRCH base="cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com" scope=1 filter="(&(objectClass=ipaassociation)(objectClass=ipacaacl))"
seems like it might be kinda key. and indeed, if I attempt to run this by hand as an anonymous bind, I get no results:
root@apex-freeipa slapd-INT-APEXMW-COM# ldapsearch -x -h localhost -b dc=int,dc=apexmw,dc=com -s sub "(|(objectClass=ipaassociation)(objectClass=ipacaacl))"
# extended LDIF
#
# LDAPv3
# base <dc=int,dc=apexmw,dc=com> with scope subtree
# filter: (|(objectClass=ipaassociation)(objectClass=ipacaacl))
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
It's only if I run this as an _authenticated_ bind, that I can find my ACL:
root@apex-freeipa slapd-INT-APEXMW-COM# ldapsearch -x -D "cn=Directory Manager" -W -h localhost -b dc=int,dc=apexmw,dc=com -s sub "(&(objectClass=ipaassociation)(objectClass=ipacaacl))" cn
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=int,dc=apexmw,dc=com> with scope subtree
# filter: (&(objectClass=ipaassociation)(objectClass=ipacaacl))
# requesting: cn
#
# c98b740c-6903-11e9-ad1b-525400b52c7b, caacls, ca, int.apexmw.com
dn: ipaUniqueID=c98b740c-6903-11e9-ad1b-525400b52c7b,cn=caacls,cn=ca,dc=int,dc
=apexmw,dc=com
cn: hosts_services_caIPAserviceCert
# 6dde33a6-7849-11e9-aa05-525400b52c7b, caacls, ca, int.apexmw.com
dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc
=apexmw,dc=com
cn: OpenVPN_User_Certificate_ACL
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
Is this (using certmonger to auto-issue signed certs/keys for my openvpn users) going to be essentially impossible to do, here? Do I need to go a more traditional route of creating a seperate keystore/certdb, issuing a CSR, and feeding that to FreeIPA to sign?
Any advice appreciated, and thanks in advance,
-- Pat
1 year, 11 months
Possible to remove trust controller role?
by Ranbir
Hi Everyone,
Is it possible to remove the trust controller role from masters? I ran
the trust agent setup on two masters that I just wanted to handle the
trust agent role and now they're showing up as trust controllers, too.
I don't know why that happened since I've done this before.
I could run the server uninstall on those two masters and enroll them
again. But, I'd like to avoid that if I can.
Thanks in advance.
--
Ranbir
1 year, 11 months
Kerberos after migration
by skrawczenko＠gmail.com
Hello again.
I gave up restoring certificates as discussed in https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
While i had to recover the service and rescue data at any cost
So my decision was probably wrong but i didn't have options
I deployed RedHat instead of CentOS and then deployed fresh IPA 4.9.8
Then i migrated directory from the old cluster excluding kerberos fields and some service accounts/groups
Rebuilt DNS etc
Initially everything was good at least users, groups and credentials were saved.
But further configuration resulted some troubles. Briefly, i can't run commands as admin and anyone else
kinit admin
Password for admin@<REALM>
[root@idm0 ~]# klist
Ticket cache: KCM:0
Default principal: admin@<REALM>
Valid starting Expires Service principal
06/20/22 07:42:19 06/21/22 06:42:23 krbtgt/<REALM>@<REALM>
[root@idm0 ~]# ipa user-show admin
ipa: ERROR: cannot connect to 'https://idm0...../ipa/session/json': Exceeded number of tries to forward a request.
kinit <any other user>
ipa user-show <any other user>
ipa: ERROR: Insufficient access: Invalid credentials
and /var/log/httpd/error.log has
ipa: INFO: 401 Unauthorized: Insufficient access: Invalid credential
What could be broken? This happened while i was trying to generate a keytab for kinit -kt <file> scripts...
1 year, 11 months
Error upon establishing trust
by Ronald Wimmer
Hi,
we have set up two more IPA environments. Today we tried to establish
the trust to the AD domain but unfortunately we were not successful:
[root@pipag01 ~]# ipa trust-add --type=ad someaddomain.at --admin
someadadmin --password
Active Directory domain administrator's password:
ipa: ERROR: CIFS server communication error: code "3221225653", message
"{Device Timeout} The specified I/O operation on %hs was not completed
before the time-out period expired." (both may be "None")
What might be the cause? Where should we take a closer look?
Cheers,
Ronald
1 year, 11 months
Problem registering CentOS 8 Client to IPA server 4.6.8-5
by Alex Bihlmaier
Hiya.
I am running IPA server 4.6.8-5 on CentOS 7 and there is an issue
registering a CentOS 8 client to this IPA System.
When using CentOS 7 registering works flawless.
On CentOS 8 it fails because:
"
Unable to initialize STARTTLS session
Connect error: TLS: hostname does not match subjectAltName in peer
certificate
Failed to bind to server!
Retrying with pre-4.0 keytab retrieval method...
Unable to initialize STARTTLS session
Connect error: TLS: hostname does not match subjectAltName in peer
certificate
Failed to bind to server!
Failed to get keytab
"
I will attach the complete log.
1 year, 11 months
"Invalid IV size (16) for CBC" when retrieving from vaults via RHEL 9 server
by Sam Morris
I've added a RHEL 9 server to my IPA domain and I am finding that 'ipa
vault-retrieve' fails intermittently.
It turns out that whenever the ipa client talks to the RHEL 9 server,
this error happens:
$ ipa vault-retrieve --service host/myhost.example.com manager-password
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/ipalib/backend.py", line 141, in
execute
return self.Command[_name](*args, **options)
File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 471,
in __call__
return self.__do_call(*args, **options)
File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 499,
in __do_call
ret = self.run(*args, **options)
File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 1229,
in run
return self.forward(*args, **options)
File "/usr/lib/python3/dist-packages/ipaclient/plugins/vault.py",
line 1069, in forward
vault_data = self._unwrap_response(
File "/usr/lib/python3/dist-packages/ipaclient/plugins/vault.py",
line 1021, in _unwrap_response
cipher = Cipher(algo, modes.CBC(nonce), backend=default_backend())
File
"/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/base.py",
line 97, in __init__
mode.validate_for_algorithm(algorithm)
File
"/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/modes.py",
line 85, in _check_iv_and_key_length
_check_iv_length(self, algorithm)
File
"/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/modes.py",
line 69, in _check_iv_length
raise ValueError(
ValueError: Invalid IV size (16) for CBC.
ipa: ERROR: an internal error has occurred
I can reproduce this both on Debian unstable (with ipalib 4.9.8-1) and
RHEL 8. I do this by overriding the value of xmlrpc_uri in
/etc/ipa/default.conf to point to the RHEL 9 server before running 'ipa
vault-retrieve'.
If I run the command on the RHEL 9 server, it works fine. I don't have a
RHEL 9 client to test with.
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
1 year, 11 months
Re: ipa-server-certinstall -k
by Fraser Tweedale
On Mon, Jun 20, 2022 at 07:49:16PM +0000, Charles Hedrick wrote:
> Keeping our own certificates up to date on the various types of
> clients is messy enough that we gave up on that.
>
> The only thing we would actually use it for is kinit -n, to
> bootstrap kinit for OTP. While kinit -n would be the most elegant
> way to do it, we have several other approaches.
>
> Documentation seems to say that if pkinit_eku_checking is set to
> kpServerAuth, we don't need the extension. I've found that kinit
> -n actually does work when the client sets this. However I have to
> install the certificates manually on the KDC, since the command
> won't do it.
This approach substitutes a certificate distribution requirement
with a config distribution requirement. Every client would have to
accept the certificate with id-kp-serverAuth instead of
id-pkinit-KPKdc** - non-default behaviour which does not conform to
RFC 4556. Some client implementations might not have a workaround.
This workaround might be acceptable for your environment. In
general, accepting certificates that do not conform to the
requirements of RFC 4556 introduces a substantial risk of FreeIPA
administrators misconfiguring their environment.
Rob & Michal, perhaps this can be considered as an RFE: to relax
this requirement via a flag, accompanied by ample warnings?
** id-pkinit-KPKdc is not required if the krbtgt/REALM principal
name appears in a id-pkinit-san otherName SAN value. But public
CAs will not include that either.
Thanks,
Fraser
> ________________________________
> From: Fraser Tweedale <ftweedal(a)redhat.com>
> Sent: Sunday, June 19, 2022 11:34 PM
> To: Charles Hedrick <hedrick(a)rutgers.edu>; Rob Crittenden via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
> Cc: Rob Crittenden <rcritten(a)redhat.com>
> Subject: Re: [Freeipa-users] Re: ipa-server-certinstall -k
>
> On Wed, Jun 15, 2022 at 04:23:30PM -0400, Rob Crittenden via FreeIPA-users wrote:
> > Charles Hedrick via FreeIPA-users wrote:
> > > the error is
> > >
> > > The KDC certificate in cert.pem, privkey.pem is not valid: invalid for a KDC
> >
> > A PKINIT certificate needs an EKU extension,
> > https://datatracker.ietf.org/doc/html/rfc4556
> >
> > When generating the key with OpenSSL you need to include "-extensions
> > kdc_cert"
> >
> It's unlikely that publicly trusted CAs will issue certs with
> id-pkinit-KPKdc in EKU. CABForum Baseline Requirements[1]
> 7.1.2.3(f) says:
>
> Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth
> [RFC5280] or both values MUST be present. id-kp-emailProtection
> [RFC5280] MAY be present. Other values SHOULD NOT be present.
>
> [1]: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.4.pdf
>
> Charles, you might need to use a certificate issued directly by the
> IPA CA for your KDC, or else do without PKINIT.
>
> Thanks,
> Fraser
>
> >
> > >
> > >
> > > ------------------------------------------------------------------------
> > > *From:* Charles Hedrick via FreeIPA-users
> > > <freeipa-users(a)lists.fedorahosted.org>
> > > *Sent:* Wednesday, June 15, 2022 3:39 PM
> > > *To:* freeipa-users(a)lists.fedorahosted.org
> > > <freeipa-users(a)lists.fedorahosted.org>
> > > *Cc:* Charles Hedrick <hedrick(a)rutgers.edu>
> > > *Subject:* [Freeipa-users] ipa-server-certinstall -k
> > >
> > > ipa-server-certinstall works fine for http and ldap. But I can't get the
> > > -k option to work.
> > >
> > > I've tried cert.pem and privkey.pem with and without chain.pem, as well
> > > as fullchain.pem and privkey.pem (fullchain has both the cert and the
> > > chain).
> > >
> > > The certs were issued by Internet2, which chains up to addtrust.
> > >
> > > kinit -n works fine if I install the pem files manually, so presumably
> > > my files are valid.
> > >
> > >
> > > _______________________________________________
> > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
> > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
> > >
> > _______________________________________________
> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>
1 year, 11 months
ipa_check_consistency - Ghost
by Kathy Zhu
Hello team,
We use ipa_check_consistency
<https://github.com/peterpakos/checkipaconsistency/blob/master/README.md> tool
to check IPA master consistency every night via cron. One of the masters
failed at Ghost last night. Here is the check for Ghost:
ldapsearch -o ldif-wrap=no -ZZ -LLLx -h ipa1.example.com -D "cn=Directory
Manager" -W -s sub -b "dc=example,dc=com"
"(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))"
nscpentrywsi
What is the significance of this inconsistency? Is there a way to fix this
other than reinitialize?
Thanks.
Kathy.
1 year, 11 months
SAN not added to requested cert
by Ranbir
Hello Everyone,
I have an AlmaLinux 9.0 client enrolled into a 4.9.8 ipa domain running
on a Rocky Linux 8.6 server. I'm running the following command on the
client to request a cert:
ipa-getcert request -I cockpit -k /etc/cockpit/ws-certs.d/0-cockpit.key
-f /etc/cockpit/ws-certs.d/0-cockpit.crt -g 2048 -K HTTP/$(hostname) -D
hostname.theinside.rnr -m 640 -M 640 -o root:cockpit-ws -O
root:cockpit-ws
The cert gets issued without error. But, I don't see the "dns" line in
the ouput:
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/etc/cockpit/ws-
certs.d/0-cockpit.key'
certificate: type=FILE,location='/etc/cockpit/ws-certs.d/0-
cockpit.crt'
CA: IPA
issuer: CN=Certificate Authority,O=THEINSIDE.RNR
subject: CN=hostname.theinside.rnr,O=THEINSIDE.RNR
issued: 2022-06-20 21:31:39 EDT
expires: 2024-06-20 21:31:39 EDT
principal name: HTTP/hostname.theinside.rnr(a)THEINSIDE.RNR
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
The result is Firefox complains about the cert when I try to visit the
cockpit web UI.
I've run it now a few times with the same result. Which one of the
myriad of logs should I check to maybe understand why this is
happening?
--
Ranbir
1 year, 11 months
