On 09/09/2016 04:09 PM, Petr Vobornik wrote:
On 09/09/2016 02:33 PM, Giorgos Kafataridis wrote:
Yes, I have followed

to the letter.
The only reason I had to recreate the cacert.p12 file is because it
is not
renewed automatically in v3, so the cacert.p12 was outdated and the
CA was
throwing an "p12 invalid digest" error.

    * I opened all necessary ports
    * I checked all certs and they are valid for another year

/Run connection check to master//
//Check connection from replica to remote master 'ipa-server.nelios'://
//   Directory Service: Unsecure port (389): OK//
//   Directory Service: Secure port (636): OK//
//   Kerberos KDC: TCP (88): OK//
//   Kerberos Kpasswd: TCP (464): OK//
//   HTTP Server: Unsecure port (80): OK//
//   HTTP Server: Secure port (443): OK//
//   PKI-CA: Directory Service port (7389): OK//
//The following list of ports use UDP protocol and would need to be//
//checked manually://
//   Kerberos KDC: UDP (88): SKIPPED//
//   Kerberos Kpasswd: UDP (464): SKIPPED//
//Connection from replica to master is OK.//
//Start listening on required ports for remote master check//
//Get credentials to log in to remote master//
//Check SSH connection to remote master//
//Execute check on remote master//
//Check connection from master to remote replica
//   Directory Service: Unsecure port (389): OK//
//   Directory Service: Secure port (636): OK//
//   Kerberos KDC: TCP (88): OK//
//   Kerberos KDC: UDP (88): OK//
//   Kerberos Kpasswd: TCP (464): OK//
//   Kerberos Kpasswd: UDP (464): OK//
//   HTTP Server: Unsecure port (80): OK//
//   HTTP Server: Secure port (443): OK//
//Connection from master to replica is OK.//
//Connection check OK/

*Even with a fresh install of centos 7 with different hostname and ip
and I
still get the  the error below*

Configuring certificate server (pki-tomcatd). Estimated time: 3
minutes 30 seconds
     [1/24]: creating certificate server user
     [2/24]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to
configure CA
instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpbMwmp_''
returned non-zero exit status 1
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the
installation logs
and the following files/directories for more information:
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
     [error] RuntimeError: CA configuration failed.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR    CA
configuration failed.

**With debug enabled I get: *

pa         : DEBUG    Starting external process
ipa         : DEBUG    args='/usr/sbin/pkispawn' '-s' 'CA' '-f'
ipa         : DEBUG    Process finished, return code=1
ipa         : DEBUG    stdout=Log file:
Loading deployment configuration from /tmp/tmpwY8XjR.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into

Installation failed.

ipa         : DEBUG
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
pkispawn    : WARNING  ....... unable to validate security domain
through REST interface. Interface not available
pkispawn    : ERROR    ....... Exception from Java Configuration
Servlet: 500
Server Error: Internal Server Error
pkispawn    : ERROR    ....... ParseError: not well-formed (invalid
token): line
1, column 0:

to obtain installation token from security domain"}

Is there a way to validate the repilca .gpg file from a v3
installation against
a v4.2 freeipa installation to check for any errors before going
through the
The ipa-replica-install completes if I don't include the --setup-ca
flag but I
don't want that

There is no automatic method to verify the replica file.

Could you share the stack trace from /var/log/pki/pki-tomcat/ca/debug  +
couple lines before and after?

Contents  of /var/log/pki/pki-tomcat/ca/debug:

[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: MessageFormatInterceptor:
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: MessageFormatInterceptor:
content-type: application/json
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: MessageFormatInterceptor:
accept: [application/json]
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: MessageFormatInterceptor:
request format: application/json
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: MessageFormatInterceptor:
response format: application/json
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: SystemConfigService:
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: SystemConfigService:
request: ConfigurationRequest [pin=XXXX, token=Internal Key Storage
Token, tokenPassword=XXXX, securityDomainType=existingdomain,
securityDomainName=null, securityDomainUser=admin,
securityDomainPassword=XXXX, isClone=true,
cloneUri=https://ipa-server.nelios:443, subsystemName=CA
ipa2-server2.nelios 8443, p12File=/tmp/ca.p12, p12Password=XXXX,
hierarchy=root, dsHost=ipa2-server2.nelios, dsPort=389, baseDN=o=ipaca,
bindDN=cn=Directory Manager, bindpwd=XXXX, database=ipaca,
secureConn=false, removeData=true, replicateSchema=false,
masterReplicationPort=7389, cloneReplicationPort=389,
issuingCA=https://ipa-server.nelios:443, backupKeys=true,
backupFile=/etc/pki/pki-tomcat/alias/ca_backup_keys.p12, adminUID=null,
adminPassword=XXXX, adminEmail=null, adminCertRequest=null,
adminCertRequestType=null, adminSubjectDN=null, adminName=null,
adminProfileID=null, adminCert=null, importAdminCert=false,
generateServerCert=true, external=false, standAlone=false,
stepTwo=false, authdbBaseDN=null, authdbHost=null, authdbPort=null,
authdbSecureConn=null, caUri=null, kraUri=null, tksUri=null,
enableServerSideKeyGen=null, importSharedSecret=null,
generateSubsystemCert=null, sharedDB=false, sharedDBUserDN=null,
createNewDB=true, setupReplication=True, subordinateSecurityDomainNamenull]
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: === Token Panel ===
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: === Security Domain Panel ===
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: Joining existing security
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: Resolving security domain
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: Getting security domain
cert chain
[09/Sep/2016:08:22:52][http-bio-8443-exec-3]: Getting install token
[09/Sep/2016:08:22:52][http-bio-8443-exec-3]: Getting install token
[09/Sep/2016:08:22:52][http-bio-8443-exec-3]: Getting old cookie
[09/Sep/2016:08:22:52][http-bio-8443-exec-3]: Token: null
[09/Sep/2016:08:22:52][http-bio-8443-exec-3]: Install token is null
[09/Sep/2016:08:22:52][http-bio-8443-exec-3]: Failed to obtain
installation token from security domain

I assume it is the null token the perpetrator ? if yes what should I fix
on master?

I don't know this part much. Therefore CCing PKI experts - in addition
to figure out if there is anything to fix on IPA or PKI side.

Endi, Matthew,

do I understand it correctly that for obtaining the token, it contacts
master server with
    pki_security_domain_user == admin
    pki_security_domain_password == whatever provided in ipa-replica-install

pki_security_domain_user matches uid=admin,ou=people,o=ipaca which has a
password which was set during ipa-server-install(and thus pkisilent) on
original 6.x server.

Therefore if admin password changed between these two installations then
it will fail obtain the cookie? (guessing that wrong credential might be
the reason)

If I look for uid=admin,ou=people,o=ipaca on master (ipa v3, centos 6.x) this is what I get:

[root@ipa-server ~]# ldapsearch -D "cn=directory manager" -W -p 389 -h localhost -b "uid=admin,ou=people,o=ipaca,dc=nelios"

# extended LDIF
# LDAPv3
# base <uid=admin,ou=people,o=ipaca,dc=nelios> with scope subtree
# filter: (objectclass=*)
# requesting: ALL

# search result
search: 2
result: 32 No such object
matchedDN: dc=nelios

# numResponses: 1

LDAP manager password seems to be correct as I used it more than once in the last few days to remove the failing replicas.
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to