[Freeipa-users] IPA PKI Questions

[Kendal Montgomery]

Excellent, thanks for the information regarding re-initialization.  I had tried this before, but I still ended up having issues in the logs where it says something along the lines of a CSN is no longer available, may need to do a full re-initializaion after I did that. It seems to only happen on some of the servers, but I wanted to make sure everything is clean at the remote sites.  I will give this a try again instead of removing and re-adding all of them.

Thanks for clearing up those details regarding the servers with CA roles and client interactions, and how to place the CA role servers. That’s very helpful!  I think it would be great if that were added to the documentation.

Thanks all!

Kendal

On 4/26/17, 5:58 PM, "Rob Crittenden" <rcritten at redhat.com> wrote:

    Kendal Montgomery wrote:
    > Hi all,
    > 
    >  
    > 
    > I’ve been struggling the last few days with rebuilding part of my
    > FreeIPA infrastructure, which has lead me to some questions about how
    > some of the IPA infrastructure works.  To give a bit of background, I
    > have two IPA servers (my initially installed IPA server, and a replica)
    > both of which have DNS, NTP, and CA roles.  I’m running CentOS 7.3,
    > FreeIPA 4.4 currently (upgraded from original CentOS 7 installations
    > which I believe was FreeIPA 4.1? initiall).  I have several remote sites
    > that each have two IPA server replicas that have replication topology
    > segments for domain and ca suffixes back to the two on-prem IPA
    > servers.  This has been working quite well for over a year now, through
    > the upgrades, etc.  Occasionally I get an issue with getting some
    > conflicting records in LDAP, which I’ve cleared up by following some of
    > the documentation out there.  It seems when this happens however, I end
    > up getting into a situation where replication stops working, and I end
    > up needing to “refresh” the installations. I have done this once so far,
    > and am in the process again currently, by deleting each remote IPA
    > server (ipa server-del), then re-installing each server to get a clean
    > copy of the databases for everything.  Last time I had no issues doing
    > this.  This time around, I’m running into some issues with the CA
    > setup.  I seem to be able to run ipa-replica-install just fine without
    > the --setup-ca option.  I may be running into some issues identified in
    > an earlier post this week, so I’ll ask about this issue separately if I
    > continue to have problems.  In working through these issues, I realized
    > I don’t really know enough about how the interaction between the IPA
    > clients and IPA server is working, with regard to the PKI
    > infrastructure.  I have some questions on what server roles I need at
    > each site and how the PKI infrastructure works within the IPA
    > environment, and how the clients communicate to it:
    > 
    
    You don't need to uninstall a master in order to fix replication issues.
    You can re-initialize it from a working master. I'm pretty sure that if
    you re-init one you need to re-init them all though, to be safe. I cc'd
    a couple of 389-ds devs to clarify.
    
    > 
    > 1)       How do the IPA clients discover servers with the CA role and
    > use them?
    
    They don't, they talk to one of the IPA masters and lets that figure it out.
    
    An IPA master does this by looking at cn=<host>,
    cn=masters,cn=ipa,cn=etc,$SUFFIX
    
    > 2)       Is all this interaction done through APIs on the IPA server –
    > in other words, are these requests fielded by the IPA server and proxied
    > somehow to known servers with the CA role?
    
    Right.
    
    > 3)       Do the clients need “direct” access to a server with the CA
    > role to request and obtain certificates and renewals? (i.e. do I need
    > each IPA server to have the CA role)?
    
    Nope.
    
    > 4)       Is it sufficient to just have one server with CA role at each
    > site?  Or even just one at the main on-prem site?
    
    One per site may be sufficient, you want to ensure that you have > 1 CAs
    and since you have separate sites, having one at each would give you
    lots of leeway in case of catastrophe.
    
    rob