Help ipa-server-upgrade command failed, exception: NetworkError: cannot connect to https://hostname.ipa.example.com:8443/ca/rest/account/login [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)
by Polavarapu Manideep Sai
Hi Team,
Facing below error while upgrading the IPA server using ipa-server-upgrade command
Please let us know the fix if any , let us know if any more details required on the same
ipa-server-upgrade command failed, exception: NetworkError: cannot connect to 'https://hostname.ipa.example.com:8443/ca/rest/account/login': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)
________________________________
DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Further, this e-mail may contain viruses and all reasonable precaution to minimize the risk arising there from is taken by OnMobile. OnMobile is not liable for any damage sustained by you as a result of any virus in this e-mail. All applicable virus checks should be carried out by you before opening this e-mail or any attachment thereto.
Thank you - OnMobile Global Limited.
1 year, 6 months
Installing DNSSEC zone and key signing keys
by Eric Ashley
Greetings all,
I'm running the following FreeIPA:
Installed Packages
freeipa-client.x86_64 4.9.10-4.fc36 @updates
freeipa-client-common.noarch 4.9.10-4.fc36 @updates
freeipa-common.noarch 4.9.10-4.fc36 @updates
freeipa-healthcheck.noarch 0.11-2.fc36 @updates
freeipa-healthcheck-core.noarch 0.11-2.fc36 @updates
freeipa-selinux.noarch 4.9.10-4.fc36 @updates
freeipa-server.x86_64 4.9.10-4.fc36 @updates
freeipa-server-common.noarch 4.9.10-4.fc36 @updates
freeipa-server-dns.noarch 4.9.10-4.fc36 @updates
libipa_hbac.x86_64 2.7.4-1.fc36 @updates
python3-ipaclient.noarch 4.9.10-4.fc36 @updates
python3-ipalib.noarch 4.9.10-4.fc36 @updates
python3-ipaserver.noarch 4.9.10-4.fc36 @updates
python3-libipa_hbac.x86_64 2.7.4-1.fc36 @updates
sssd-ipa.x86_64 2.7.4-1.fc36 @updates
My other internal DNS server is 9.16.33-1.fc36 running on the same OS revision. Both my FreeIPA subdomain and the subdomain served by the other Bind 9 instance are serving subdomains of my issued domain name but are hidden. My public DNS (also Bind9, but on Debian) is in my DMZ and accessible via local LAN links to the all FreeIPA clients. My publicly accessible hosts are not FreeIPA clients and don't lookup internal PTR records or need any integration with FreeIPA. If something really requires the DS records for the subdomains to be available, I could create a view on the public server that serves that data, including the subdomain authority delegation. I'd rather not take this step unless it's really a necessity.
I don't have any FreeIPA secondary servers at present since I can't see a point in having 2 copies of the same server running as VMs on the same host machine. As I lack another machine with sufficient power to run FreeIPA server, I just backup regularly. Therefore, the packages that manage a fleet of servers are unnecessary overhead, since I have just 1.
ipa dnszone-show returns the following as the first line of output, followed by the other settings looking as expected:
ipa: WARNING: No DNSSEC key master is installed. DNSSEC zone signing will not work until the DNSSEC key master is installed.
I have created ZSK and KSK keys for the ipa subdomain. I'm wondering if there's an easier way to import them than manually creating the DNSKEY 256 and 257 records. I've searched, fruitlessly, for the information in the doc and can only find passing references to DNSSEC, with no key import instructions.
rndc dnssec -status <myipa>.domain.com
reports
Zone does not have dnssec-policy
Do I change that in named config files or is there a prefered way to set it via freeipa? After I sent my first attempt at this message, I stumbled upon the fact that Bind had updated to support a fully automatic key management. At my last digging, it still required the admin to generate and install keys manually. All my other servers are properly using the default dnssec-policy and inline-signing is yes.
At some point I'll remember that I can't send mailing list emails from Thunderbird without ProtonMail signing it.
Thanks in advance,
Eric
Sent with Proton Mail secure email.
1 year, 6 months
Installing DNSSEC zone and key signing keys
by Eric Ashley
Greetings all,
I'm running the following FreeIPA:
Installed Packages
freeipa-client.x86_64 4.9.10-4.fc36 @updates
freeipa-client-common.noarch 4.9.10-4.fc36 @updates
freeipa-common.noarch 4.9.10-4.fc36 @updates
freeipa-healthcheck.noarch 0.11-2.fc36 @updates
freeipa-healthcheck-core.noarch 0.11-2.fc36 @updates
freeipa-selinux.noarch 4.9.10-4.fc36 @updates
freeipa-server.x86_64 4.9.10-4.fc36 @updates
freeipa-server-common.noarch 4.9.10-4.fc36 @updates
freeipa-server-dns.noarch 4.9.10-4.fc36 @updates
libipa_hbac.x86_64 2.7.4-1.fc36 @updates
python3-ipaclient.noarch 4.9.10-4.fc36 @updates
python3-ipalib.noarch 4.9.10-4.fc36 @updates
python3-ipaserver.noarch 4.9.10-4.fc36 @updates
python3-libipa_hbac.x86_64 2.7.4-1.fc36 @updates
sssd-ipa.x86_64 2.7.4-1.fc36 @updates
On the following Fedora revision:
5.19.12-200.fc36.x86_64
My other internal DNS server is9.16.33-1.fc36 running on the same OS
revision. Both my FreeIPA subdomain and the subdomain served by the
other Bind 9 instance are serving subdomains of my issued domain name
but are hidden. My public DNS (also Bind9, but on Debian) is in my DMZ
and accessible via local LAN links to the all FreeIPA clients. My
publicly accessible hosts are not FreeIPA clients and don't lookup
internal PTR records or need any integration with FreeIPA. If something
really requires the DS records for the subdomains to be available, I
could create a view on the public server that serves that data,
including the subdomain authority delegation. I'd rather not take this
step unless it's really a necessity.
I don't have any FreeIPA secondary servers at present since I can't see
a point in having 2 copies of the same server running as VMs on the same
host machine. As I lack another machine with sufficient power to run
FreeIPA server, I just backup regularly. Therefore, the packages that
manage a fleet of servers are unnecessary overhead, since I have just 1.
ipa dnszone-show returns the following as the first line of output,
followed by the other settings looking as expected:
ipa: WARNING: No DNSSEC key master is installed. DNSSEC zone signing
will not work until the DNSSEC key master is installed.
I have created ZSK and KSK keys for the ipa subdomain. I'm wondering if
there's an easier way to import them than manually creating the DNSKEY
256 and 257 records. I've searched, fruitlessly, for the information in
the doc and can only find passing references to DNSSEC, with no key
import instructions.
I do still need to create and sign the IPv4 class B levels of the
in-addr.arpa addresses to provide the DS records for the PTR validation
on my FreeIPA master. That, however, is secondary to getting my keys
into FreeIPA in the first place. I suppose I could have my other
private server inline sign them and do all lookups there, rather than on
the FreeIPA DNS instance, but I'd rather not alter the default FreeIPA
client setup if I don't have to.
Thanks in advance,
Eric
1 year, 6 months
Re: Dogtag cert for Active Directory users?
by Alexander Bokovoy
(don't drop the mailing list, please)
On la, 01 loka 2022, Sami Hulkko wrote:
>well,
>
>For starters it would be quite rational and practical to provide
>certificates for Samba AD and it's users trough IPA Dogtag rather then
>having a second certificate system for it. Wouldn't it?
I would see this a completely separate task and is not relevant to IPA
itself.
You'd want to issue certificates to some entities that do not
exist in IPA. For this you are practically not required to be bound by
IPA itself, it is something that can be achieved with Dogtag services
directly. We do not hide them so if you have set up an ACL that allows
to authenticate to Dogtag and be granted certain privileges, you can
issue certificates by the Dogtag instance that runs IPA CA as well.
If you'd still want to bind a check to existence of an ID override of a
user, that would need some fixes in IPA:
- fix cert_request.lookup_principal() to also look at the ID overrides
in the 'Default Trust View' ID view
- add support for 'mail' attribute into user ID overrides to be able to
match certificate requests. This should not be writable to users
themselves (a default state in IPA)
- fix cert_request.execute() to consider ID overrides as 'principals'
returned by the cert_request.lookup_or_add_principal() (which calls
lookup_principal()). There are quite a few differences, the most
important one is that ID overrides aren't Kerberos principals so they
don't have krbPrincipalName/krbCanonicalName attributes at all. They
have ipaOriginalUid attribute which can be used to match a a Kerberos
principal.
- fix CA ACL checks to allow use of ID override-bound principals
May be more to do. If you want to implement this, feel free to open a
ticket and submit a pull request and we can work it out there. It
certainly could be implemented so any contribution is welcomed.
>
>SH
>
>On 01/10/2022 13:19, Alexander Bokovoy wrote:
>>On la, 01 loka 2022, Sami Hulkko via FreeIPA-users wrote:
>>>Hi,
>>>
>>>Is it possible to provide certificate (Dogtag) for AD trusted user
>>>that has login rights to IPA trough ID override?
>>
>>I'd ask a question in advance: what this certificate would be used for?
>>
>>ID overrides aren't real users, so you wouldn't be able to use that for
>>login purposes. Users from trusted Active Directory domains get
>>authenticated by their own domain's domain controllers, not IPA. So you
>>cannot use that certificate for something on IPA side other than an SSH
>>public key authentication. For this, it does not matter who issued the
>>certificate, any user has a self-service right to update ipaSSHPubKey
>>attribute, including AD users who can update their own override.
>>They can also update their own userCertificate attribute according to
>>one of default access controles:
>>
>>aci: (targetattr = "usercertificate")(version 3.0;acl
>>"selfservice:Users can manage their own X.509 certificates";allow
>>(write) userdn = "ldap:///self";)
>>
>>but where they could be using this certificate to match for?
>>
>>In addition, IPA framework does check properties of the accounts that
>>request certificate issuance and only allows to issue certificates to
>>IPA users, IPA hosts, and IPA services. ID overrides aren't included,
>>for reasons outlined above.
>>
>>For more details on how IPA certificate issuance checks done please see
>>my response to Sam Morris in May 2022:
>>https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>
>>
>--
>Me worry? That's why my first CD was Peter Gabriel SO....
>
>Sami Hulkko
>sahulkko(a)gmail.com
>sahulkko(a)icloud.com
>samihulkko(a)quantum-black-hole.com
>+358 45 85693 919
>BEGIN:VCARD
>VERSION:4.0
>EMAIL;PREF=1:samihulkko@quantum-black-hole.com
>EMAIL:sahulkko@gmail.com
>FN:Sami Hulkko
>NICKNAME:Atol
>N:Hulkko;Sami;;;
>TEL;VALUE=TEXT:+358458569319
>X-MOZILLA-HTML;VALUE=BOOLEAN:FALSE
>UID:53ad98cb-d6b2-4667-a26c-6f564a428e51
>END:VCARD
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
1 year, 6 months
Dogtag cert for Active Directory users?
by Sami Hulkko
Hi,
Is it possible to provide certificate (Dogtag) for AD trusted user that
has login rights to IPA trough ID override?
--
Me worry? That's why my first CD was Peter Gabriel SO....
Sami Hulkko
sahulkko(a)gmail.com
sahulkko(a)icloud.com
samihulkko(a)quantum-black-hole.com
+358 45 85693 919
1 year, 6 months
