On 2016-03-31 11:56, Fraser Tweedale wrote:
On Thu, Mar 31, 2016 at 09:49:20AM +0200, Martin Štefany wrote:
Hello Fraser,

here are the files for real, thank you for help.


Thanks Martin,

So what appears to have happened is somehow the default profile
`caIPAserviceCert`, which is shipped with Dogtag, was imported into
LDAP instead of the version shipped with IPA.  I do not know how
this might have occurred - it will help to know the history of your
installation e.g. was it a fresh install, upgrade from a Centos/RHEL
7.1, migration (ipa-replica-install) of an earlier version, etc.

In any case, how to resolve?  You can import a corrected version of
the profile.  I have attached an example config, but you should
check it to make sure it is what you want; in particular check the
following values:





You can update the profile with the new profile data by executing:

ipa certprofile-mod caIPAserviceCert --file=/path/to/caIPAserviceCert.cfg

Hopefully this fixes the issue.

A fallback suggestion: if the above command fails, and if `ipa
certprofile-find` shows no objects, then you may be able to resolve
the issue by setting, in `/etc/pki/pki-tomcat/ca/CS.cfg`:


and then running `ipa-server-upgrade` manually.

I am on PTO tomorrow but look forward to learning on Monday how you
fared.  Others may be able to help in the meantime.


Hello Fraser,

yes, that solves the issue. 'ipa certprofile-mod caIPAserviceCert --file=/path/to/caIPAserviceCert.cfg' was successful, and newly issued certificate is with correct attributes as before.

# ipa-getcert request -k /etc/pki/tls/private/http.key -f /etc/pki/tls/certs/http.pem -N CN=$(hostname -f) -D $(hostname -f) -D www.example.com -K HTTP/$(hostname -f)
# ipa-getcert list
Number of certificates and requests being tracked: 1.
Request ID '20160331113029':
        status: MONITORING
        stuck: no
key pair storage: type=FILE,location='/etc/pki/tls/private/http.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/http.pem'
        CA: IPA
        issuer: CN=Certificate Authority,O=EXAMPLE.COM
        subject: CN=http2.example.com,O=EXAMPLE.COM
        expires: 2018-04-01 11:30:33 UTC
        dns: http2.example.com,www.example.com
        principal name: HTTP/http2.example....@example.com
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
        eku: id-kp-serverAuth,id-kp-clientAuth
        pre-save command:
        post-save command:
        track: yes
        auto-renew: yes

Great job!

The history would be:

- idmc1 was installed first on CentOS 7.1 as IPA 4.0
- replica file was created from this idmc1 and replica was provisioned as idmc2 again on CentOS 7.1 as IPA 4.0 - upon release of CentOS 7.2, idmc2 was "yum" upgraded to CentOS 7.2 / FreeIPA 4.2, everything was OK, so
- idmc1 was "yum" upgraded to CentOS 7.2 / FreeIPA 4.2
- time flies...
- recently I've created another replica file from idmc1 for idmc3 and replica idmc3 was provisioned on fresh CentOS 7.2 / IPA 4.2,
  and this might have been the moment when something got broken. :(
- http1, http2, etc. were provisioned only after idmc3 was deployed

Thank you for the steps! I will also mail you ipa-server install/upgrade logs from all three systems in separate mail, if you don't mind, to try to see what exactly happened.

btw, after I executed 'ipa certprofile-mod caIPAserviceCert --file=/path/to/caIPAserviceCert.cfg', certmonger stopped to see/track all 'CN=*,OU=pki-ipa,O=IPA' certificates and reported 'Number of certificates and requests being tracked: 0.', but I was going to re-provision the certificates anyway.

Enjoy your longer weekend!


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to