[Freeipa-users] Install IPA Servers with third-party certificate(external CA)

beeth beeth beeth2006 at gmail.com
Fri Sep 30 02:03:08 UTC 2016


Thanks Florence and Rob! The replica worked after adding the certs during
the replica preparation.

Now I got several IPA clients installed with user authentication(ssh login
with the users in IPA) working after some work. However, one of them failed
during login with the following messages in syslog:

Sep 29 21:41:13 ipaclient3 [sssd[krb5_child[2527]]]: Credentials cache
permissions incorrect
Sep 29 21:41:13 ipaclient3 [sssd[krb5_child[2527]]]: Decrypt integrity
check failed
Sep 29 21:41:13 ipaclient3 [sssd[krb5_child[2527]]]: Decrypt integrity
check failed

I tried this on ipaclient3:
# kinit admin
# ipa-getkeytab -s ipa1.example.com -p host/ipaclient3.example.com -k
/etc/krb5.keytab
No help.

I also tried this on ipaclient3(which I don't think is relevant to the krb5
error):
# wget -O /etc/ipa/ca.crt https://ipa1.example.com/ipa/config/ca.crt
# certutil -A -d /etc/pki/nssdb -n "IPA CA" -t CT,C,C -a -i /etc/ipa/ca.crt

Any idea about such krb5 issue? Thanks again!



On Thu, Sep 29, 2016 at 9:36 AM, Florence Blanc-Renaud <flo at redhat.com>
wrote:

> On 09/29/2016 02:12 PM, Rob Crittenden wrote:
>
>> beeth beeth wrote:
>>
>>> Hi Florence,
>>>
>>> I previously tried option a) and failed(need to find out why later), but
>>> I was able to successfully reinstall the server and the client with
>>> option b), thanks a lot! So when it says "Installing Without a CA", it
>>> means without a "embeded CA"(the IPA's own CA), is that right?
>>>
>>> Another main problem comes up for option b): now I am going to install
>>> the replica server(ipa2), if I do the same as I did before:
>>>
>>> [root at ipa1 ~]# ipa-replica-prepare ipa2.example.com
>>> <http://ipa2.example.com>
>>>
>>> copy the gpg file from ipa1 to ipa2
>>>
>>> [root at ipa2 ~]# ipa-replica-install
>>> /var/lib/ipa/replica-info-ipa2.example.com.gpg
>>>
>>> Then I believe the Apache on ipa2(the replica server) will use the
>>> Verisign certificate with the same hostname(DN): ipa1.example.com
>>> <http://ipa1.example.com>, NOT ipa2.example.com
>>> <http://ipa2.example.com>, hence the users who visit
>>> https://ipa2.example.com will experience security warning from the
>>> browser, as expected...
>>> What could be a solution for this?
>>>
>>> Thanks again!
>>>
>>>
>>> On Thu, Sep 29, 2016 at 6:03 AM, Florence Blanc-Renaud <flo at redhat.com
>>> <mailto:flo at redhat.com>> wrote:
>>>
>>>     On 09/29/2016 11:43 AM, beeth beeth wrote:
>>>
>>>         Thanks for the quick response Florence!
>>>
>>>         My goal is the use a 3rd party certificate(such as Verisign
>>>         cert) for
>>>         Web UI(company security requirement), in fact we are not
>>>         required to use
>>>         3rd party certificate for the LDAP server, but as I mentioned
>>>         earlier, I
>>>         couldn't make the new Verisign cert to work with the Web UI,
>>> without
>>>         messing up the IPA function(after I updated the nss.conf to use
>>>         the new
>>>         cert in the /etc/httpd/alias db, the ipa_client_install failed).
>>>         So I
>>>         tried to follow the Redhat instruction, to see if I can get the
>>>         Verisign
>>>         cert installed at the most beginning, without using FreeIPA's
>>>         own/default certificate), but I got the CSR question.
>>>
>>>         I did install IPA without a CA, by following the instruction at
>>>
>>> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
>>>
>>> <https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
>>> >,
>>>         but failed to restart HTTPD. When and how can I provide the
>>>         3rd-party
>>>         certificate? Could you please point me a document about the
>>> detail?
>>>
>>>     Hi,
>>>
>>>     you need first to clarify if you want FreeIPA to act as a CA or not.
>>>     The setup will depend on this choice.
>>>
>>>     - option a) FreeIPA with an embedded CA:
>>>     you can install FreeIPA with a self-signed CA, then follow the
>>>     instructions at
>>>
>>> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
>>>
>>> <https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP>
>>>     in order to replace the WebUI certificate. Please note that there
>>>     were some bugs in ipa-server-certinstall, preventing httpd from
>>>     starting (Ticket #4786 [1]). The workaround is to manually update
>>>     nss.conf (as you did) and manually import the CA certificate into
>>>     /etc/pki/pki-tomcat/alias, for instance with
>>>     $ certutil -A -d /etc/pki/pki-tomcat/alias -i cacert.pem -n nickname
>>>     -t C,,
>>>
>>>
>>>     - option b) Free IPA without CA
>>>     the installation instructions are in Installing without a CA [2].
>>>     You will provide the certificate that will be used by both the LDAP
>>>     server and the WebUI in the command options.
>>>
>>
>> You'd need either a separate certificate or one with multiple subject
>> alternative names, one for each master. I also imagine you'd need to
>> provide this certificate at replica preparation time if you've installed
>> without a CA.
>>
>> Yes, that's right. You can use the command ipa-replica-prepare with the
> options --dirsrv-cert-file / --dirsrv-pin and --http-cert-file / --http-pin
> to provide the replica's certificate and key. They will be embedded in the
> replica file and used during the replica installation.
>
> Flo.
>
>
> rob
>>
>>
>>>     HTH,
>>>     Flo.
>>>
>>>     [1] https://fedorahosted.org/freeipa/ticket/4786
>>>     <https://fedorahosted.org/freeipa/ticket/4786>
>>>     [2]
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterp
>>> rise_Linux/7/html/Linux_Domain_Identity_Authentication_and_
>>> Policy_Guide/install-server.html#install-server-without-ca
>>>
>>>
>>> <https://access.redhat.com/documentation/en-US/Red_Hat_Enter
>>> prise_Linux/7/html/Linux_Domain_Identity_Authentication_and_
>>> Policy_Guide/install-server.html#install-server-without-ca>
>>>
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160929/3b754df4/attachment.htm>


More information about the Freeipa-users mailing list