On 08/30/2013 10:23 AM, Bret Wortman wrote:
Morning update. I made the change Rob suggested to
/etc/ipa/default.conf, which appeared to work, but didn't quite. It
asked me to back out the whole server installation and start over:
[ipamaster2]# ipa-ca-install --skip-conncheck
replica-info-ipamaster2.foo.net.gpg
Directory Manager (existing master) password:
COnfiguring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
[1/16]: creating certificate server user
[2/16]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpVC28HP' returned non-zero exit status 1
Your system may be partly configured.
Run/usr/sbin/ipa-server-install --uninstall to clean up.
Can you look into /var/log/ipareplica-ca-install.log? It should have
more information on what caused pkispawn to fail.
Configuration of CA failed.
[ipamaster2]#
Which uninstallation & cleanup I did.
Now, when trying to re-install the
replica file:
[ipamaster2]# ipa-replica-install --setup-dns --no-forwarders --setup-ca
/var/lib/ipa/replica-info-ipamaster2.foo.net.gpg
Directory manager (existing master) password:
Run connection check to master
Check connection from replica to remote master 'ipamaster.foo.net
<http://ipamaster.foo.net>':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (686): OK
Kerberos KDC: TCP (88): OK
Kerberos Kpasswd: TCP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK
The followign 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
[email protected] <mailto:[email protected]> password:
Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'ipamaster2.foo.net
<http://ipamaster2.foo.net>':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (686): 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
The host ipamaster2.foo.net <http://ipamaster2.foo.net> already exists
on the master server.
You should remove it before proceeding:
% ipa host-del ipamaster2.foo.net <http://ipamaster2.foo.net>
ipa : ERROR Could not resolve hostname ipamaster.foo.net
<http://ipamaster.foo.net> using DNS Clients may not function properly.
Please check your DNS setup. (Note that this check queries IPA DNS
directly and ignores /etc/hosts.)
Continue? [no]: *yes*
[ipamaster2]# host ipamaster.foo.net <http://ipamaster.foo.net>
ipamaster.foo.net <http://ipamaster.foo.net> has address 1.2.3.4
No matter what answer I give to the "Continue?" prompt, it just exits.
"nslookup" returns the same value, and I have three different
nameservers configured for this host (including ipamaster and two of the
older replicas).
The error that caused the installation to fail is that
ipamaster2.foo.net already exists on the master server.
The DNS warning and its "Continue?" prompt is unrelated, but the order
of the output is very confusing. I've filed ticket 3889 for this.
Anyway, to do this DNS resolution check you'd need to explicitly ask for
the IPA server:
$ dig @ipamaster.foo.net ipamaster2.foo.net
And this message is the one that has prompted me to want to delete hosts
before installing in the past, Simo.
Any thoughts on how best to proceed now?
I believe you do need to delete he host at this point, but I'd rather
have Rob or Simo confirm.
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
On Thu, Aug 29, 2013 at 2:59 PM, Rob Crittenden <[email protected]
<mailto:[email protected]>> wrote:
Bret Wortman wrote:
Okay, I got the cacert.p12 (turns out it was taking my
passphrase, but
the messages looked like errors to my addled eyes). This system
is on a
different network, so getting the file transferred would take me
about
24 hours. Is there something I can get that'll tell you what you
need
but is plaintext?
Ok, that's fine.
Try this. Set ra_plugin to dogtag in /etc/ipa/default.conf. This
will let it get past the error and it should install a CA. I'm
trying to think worst case scenario what it might do and I'm not
coming up with anything. I think the worst that happens is that
adding a CA fails later.
rob
I tried this and hope this subset of information is helpful:
# openssl pkcs12 -in cacert.p12 -out cacert.pem.bdw -cacerts -nokeys
# cat cacert.pem.bdw
Bag Attributes: <No Attributes>
subject=/O=FOO.NET/CN=__Certificate
<http://FOO.NET/CN=Certificate>
<http://FOO.NET/CN=Certificate__> Authority/
issuer=/O=FOO.NET/CN=__Certificate
<http://FOO.NET/CN=Certificate>
<http://FOO.NET/CN=Certificate__> Authority
-----BEGIN CERTIFICATE-----
MIIDgzCCA...
...Iwk4r
-----END CERTIFICATE-----
# openssl pkcs12 -in cacert.p12 -out cert.pem.bdw -clcerts -nokeys
# cat cert.pem.bdw
Bag Attributes:
localKeyID: 82 81 2D 6E 5C 13 43 9A 5F BB C8 4D F5 6B DE
6C A7 2E 53 88
friendlyName: caSigningCert cert-pki-ca
subject=/O=FOO.NET/CN=__Certificate
<http://FOO.NET/CN=Certificate>
<http://FOO.NET/CN=Certificate__> Authority
issuer=/O=FOO.NET/CN=__Certificate
<http://FOO.NET/CN=Certificate>
<http://FOO.NET/CN=Certificate__> Authority
-----BEGIN CERTIFICATE-----
MIIDgzCCA...
...Iwk4r
-----END CERTIFICATE-----
Bag Attributes:
localKeyID: 88 BF DF 56 30 BB A9 47 12 D4 5F 7B AE 39 DC
BF CF F5 92 22
friendlyName: ocspSigningCert cert-pki-ca
subject=/O=FOO.NET/CN=OCSP <http://FOO.NET/CN=OCSP>
<http://FOO.NET/CN=OCSP> Subsystem
issuer=/O=FOO.NET/CN=__Certificate
<http://FOO.NET/CN=Certificate>
<http://FOO.NET/CN=Certificate__> Authority
-----BEGIN CERTIFICATE-----
MIIDYTCCA...
...wlr4Q=
-----END CERTIFICATE-----
Bag Attributes:
localKeyID: B5 3B 27 CC 57 72 45 E2 8D 46 C9 5E E1 C0 50
DF 2D 11 62 0E
friendlyName: subsystemCert cert-pki-ca
subject=/O=FOO.NET/CN=CA <http://FOO.NET/CN=CA>
<http://FOO.NET/CN=CA> Subsystem
issuer=/O=FOO.NET/CN=__Certificate
<http://FOO.NET/CN=Certificate>
<http://FOO.NET/CN=Certificate__> Authority
-----BEGIN CERTIFICATE-----
MIIDaTCCA...
...BxqqA==
-----END CERTIFICATE-----
Bag Attributes:
localKeyID: 1F 69 62 C7 88 D8 95 2A B1 7D 61 F9 10 87 14
D0 76 Ba B9 44
friendlyName: auditSigningCert cert-pki-ca
subject=/O=FOO.NET/CN=CA <http://FOO.NET/CN=CA>
<http://FOO.NET/CN=CA> Audit
issuer=/O=FOO.NET/CN=__CertificateAUthority
<http://FOO.NET/CN=CertificateAUthority>
<http://FOO.NET/CN=__CertificateAUthority
<http://FOO.NET/CN=CertificateAUthority>>
-----BEGIN CERTIFICATE-----
MIIDRDCCA...
...EAd+Ug7
-----END CERTIFICATE-----
# openssl pkcs12 -in cacert.p12 -out key.pem.bdw -nocerts
# cat key.pem.bdw
Bag Attributes
localKeyID: 82 81 2D 6E 5C 13 43 9A 5F BB C8 4D F5 6B DE
6C A7 2E 53 88
friendlyName: CN=Certificate Authority,O=FOO.NET
<http://FOO.NET> <http://FOO.NET>
Key Attributes: <No Attributes>
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFDjBAB...
...XLtoD8=
-----END ENCRYPTED PRIVATE KEY-----
Bag Attributes
localKeyID: <let me know if you need this>
friendlyName: CN=OCSP Subsystem,O=FOO.NET <http://FOO.NET>
<http://FOO.NET>
Key Attributes: <No Attributes>
-----BEGIN ENCRYPTED PRIVATE KEY-----
:
-----END ENCRYPTED PRIVATE KEY-----
Bag Attributes
localKeyID: <let me know if you need this>
friendlyName: CN=CA Subsystem,O=FOO.NET <http://FOO.NET>
<http://FOO.NET>
Key Attributes: <No Attributes>
Bag Attributes
localKeyID: <let me know if you need this>
friendlyName: CN=CA Audit,O=FOO.NET <http://FOO.NET>
<http://FOO.NET>
Key Attributes: <No Attributes>
If you need to see anything else, please let me know.
_
_
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
On Thu, Aug 29, 2013 at 11:58 AM, Rob Crittenden
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Bret Wortman wrote:
On Thu, Aug 29, 2013 at 11:40 AM, Rob Crittenden
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>____wrote:
Bret Wortman wrote:
On Thu, Aug 29, 2013 at 11:10 AM, Rob Crittenden
<[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
<mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
<mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>__> wrote:
Bret Wortman wrote:
A bit of googling has led me to
understand
that we must
have
created the
original server with --selfsign, and that
locked us into
something bad
which is now causing us problems. I'm
not sure
how this
happened, since
we actually created our original
instance on a
different server,
created
ipamaster as a replica of that one,
then ran
ipa-ca-install on
ipamaster
to make it the new CA. How did it end
up in
this state?
Anyway, is there ANY way around this?
Can I simply
ignore this,
break
the replication agreement as Simo
suggested,
rebuild
ipamaster,
replicate ipamaster2 to the new
ipamaster, and
then
somehow make
ipamaster be a CA using Dogtag? Will that
screw up all
the clients?
I think we should pause and take a look
at your
installation.
I'd check all your current masters,
whether they
are currently
working or not. Look at the value of
ra_plugin in
/etc/ipa/default.conf. That controls what IPA
thinks the CA is.
on ipamaster: ra_plugin=dogtag
and either that same value or the ra_plugin
doesn't
exist on the
replicas. On ipamaster2, the one I just installed,
there is no
ra_plugin
in the file.
Then check to see if you have dogtag
running on
any of these
systems. This will include a 2nd 389-ds
instance,
/etc/dirsrv/slapd-PKI-IPA and, depending
on your
distro, a PKI
service like
pki-tomcatd@pki-tomcat.________service.
You can
optionally
see if /etc/pki/pki-tomcat exists.
ipamaster definitely has a
/etc/dirsrv/slapd-PKI-IPA
directory, with
files updated fairly recently (within the past
30 minutes -
lse.ldif and
lse.ldif.bak, others updated yesterday). I
also have a
[email protected] file and a
pki-tomcatd.target. no
/etc/pki/pki-tomcat.
ipamaster2 only has /etc/dirsrv/slapd-FOO-NET.
It does have
pki-tomcatd.target and [email protected]. No
/etc/pki/pki-tomcat.
Ok. When you created the replica file for
ipamaster2, did
you create
it on ipamaster? Only a replica that is a CA can
create a
replica
with a CA.
Yes. So I'm not sure what went askew.
Ok. I think we need to see what's in the prepared file. It
is just a
gpg-encrypted tarball. Can you do something like:
gpg -d replica-info-pacer.greyoak.____com.gpg |tar xf -
This will create a realm_info subdirectory. The file cacert.p12
should be in there.
rob
_______________________________________________
Freeipa-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Petr³
_______________________________________________
Freeipa-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-users
