ipaCertSubject uniqueness check

[Khurrum Maqb]

I'm currently running ipaServer 4.6.8 on Centos7. I have an IPA CA, and an external CA
for user smartcard authentication provided by a third party. I have used ipa-cacart-manage
to add the external CA chain to IPA, and it worked fine. 

The external CA re-keyed one of the certs in the chain, and kept the subject name the
same. So the key, serial, expiration are different, but the placement in the chain, the
the ipaCertSubject are the same. Both the old cert and the new one are valid, and some
cards have the old chain still valid, and some have the new chain valid. 

So if I go and try to use ipa-cacert-manage to add the NEW cert, I get "Failed to
install the certificate: subject public key info mismatch" which I assume is due to
the ipaCertSubject being the same (docs:
https://www.freeipa.org/page/V4/CA_certificate_renewal )

Is this expected behavior? Is there a workaround? Or will i have to use ldapdelete and
certutil -D to delete the old key, and then install the new key. In this process, the
users with the OLD key will lose the ability to log in with their smart cards until new
certs are issued to them. Thanks!

[Khurrum Maqb]

I got it resolved - IPA does not seem to support importing a rechained external CA. It
doesn't seem to have anything to do with ipaCertSubject being unique but it's
something else where there are two different chains for the same external CA.

I was able to ldapdelete the old problematic certs from ldap> etc > ipa >
certificates. And then I was able to successfully run the ipa-advise script for adding the
CA certs. This time ipa-cacert-manage worked without throwing the public key info mismatch
error. 

And then I ran ipa-certupdate on all Ipa servers, and clients that required smartcard
auth. And it seemed to work fine for the new certs. Unfortunately, this likely means that
the cards with the old chain will stop working but they are in the small minority and
we'll likely have to get them new cards signed by the external CA with the new chain.


I would like to suggest that the ability to rechain and have two different chains for the
same external CA be added to FreeIPA. It's likely a rare situation but it happens.

[Fraser Tweedale]

On Sat, Dec 12, 2020 at 05:49:53PM -0000, Khurrum Maqb via FreeIPA-users wrote:
>  I got it resolved - IPA does not seem to support importing a
>  rechained external CA. It doesn't seem to have anything to do with
>  ipaCertSubject being unique but it's something else where there
>  are two different chains for the same external CA.
>  
>  I was able to ldapdelete the old problematic certs from ldap> etc
>  > ipa > certificates. And then I was able to successfully run the
>  > ipa-advise script for adding the CA certs. This time
>  > ipa-cacert-manage worked without throwing the public key info
>  > mismatch error. 
>  
>  And then I ran ipa-certupdate on all Ipa servers, and clients that
>  required smartcard auth. And it seemed to work fine for the new
>  certs. Unfortunately, this likely means that the cards with the
>  old chain will stop working but they are in the small minority and
>  we'll likely have to get them new cards signed by the external CA
>  with the new chain. 
>  
>  I would like to suggest that the ability to rechain and have two
>  different chains for the same external CA be added to FreeIPA.
>  It's likely a rare situation but it happens.  
Thanks for the report Khurrum.  Glad you were able to sort it out.

Rob, Flo: this is old validation code (commit de695e688e, 2014) and
probably an oversight.  We should investigate whether anything
breaks when superior certs in the IPA CA chain get rekeyed.  If
nothing breaks, we should remove the SubjectPublicKeyInfo check.

Cheers,
Fraser

[Rob Crittenden]

Fraser Tweedale wrote:
>  On Sat, Dec 12, 2020 at 05:49:53PM -0000, Khurrum Maqb via
> FreeIPA-users wrote:
> > I got it resolved - IPA does not seem to support importing a
> > rechained external CA. It doesn't seem to have anything to do with
> > ipaCertSubject being unique but it's something else where there
> > are two different chains for the same external CA.
> >
> > I was able to ldapdelete the old problematic certs from ldap> etc
> >> ipa > certificates. And then I was able to successfully run the
> >> ipa-advise script for adding the CA certs. This time
> >> ipa-cacert-manage worked without throwing the public key info
> >> mismatch error.
> >
> > And then I ran ipa-certupdate on all Ipa servers, and clients that
> > required smartcard auth. And it seemed to work fine for the new
> > certs. Unfortunately, this likely means that the cards with the
> > old chain will stop working but they are in the small minority and
> > we'll likely have to get them new cards signed by the external CA
> > with the new chain.
> >
> > I would like to suggest that the ability to rechain and have two
> > different chains for the same external CA be added to FreeIPA.
> > It's likely a rare situation but it happens.
>  
>  Thanks for the report Khurrum.  Glad you were able to sort it out.
>  
>  Rob, Flo: this is old validation code (commit de695e688e, 2014) and
>  probably an oversight.  We should investigate whether anything
>  breaks when superior certs in the IPA CA chain get rekeyed.  If
>  nothing breaks, we should remove the SubjectPublicKeyInfo check. 
At one time NSS didn't like different certificates with the same 
subjects. Things may have changed.

rob