freeipa/install/tools/ipa-ca-install

426 lines
16 KiB
Plaintext
Raw Normal View History

#! /usr/bin/python2 -E
# Authors: Rob Crittenden <rcritten@redhat.com>
#
# Copyright (C) 2011 Red Hat
# see file 'COPYING' for use and warranty information
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
import sys
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
import os
import shutil
from ConfigParser import RawConfigParser
from ipapython import ipautil
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
from ipaserver.install import installutils
from ipaserver.install import certs
from ipaserver.install.installutils import (HostnameLocalhost, ReplicaConfig,
expand_replica_info, read_replica_info, get_host_name, BadHostError,
private_ccache, read_replica_info_dogtag_port, load_external_cert,
create_replica_config)
from ipaserver.install import dsinstance, cainstance, bindinstance
from ipaserver.install.replication import replica_conn_check
from ipapython import version
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
from ipalib import api, certstore, x509
from ipapython.dn import DN
from ipapython.config import IPAOptionParser
from ipapython import sysrestore
from ipapython import dogtag
from ipapython import certdb
from ipapython.ipa_log_manager import *
from ipaplatform import services
from ipaplatform.paths import paths
log_file_name = paths.IPAREPLICA_CA_INSTALL_LOG
REPLICA_INFO_TOP_DIR = None
def parse_options():
usage = "%prog [options] REPLICA_FILE"
parser = IPAOptionParser(usage=usage, version=version.VERSION)
parser.add_option("-d", "--debug", dest="debug", action="store_true",
default=False, help="gather extra debugging information")
parser.add_option("-p", "--password", dest="password", sensitive=True,
help="Directory Manager (existing master) password")
parser.add_option("-w", "--admin-password", dest="admin_password", sensitive=True,
help="Admin user Kerberos password used for connection check")
parser.add_option("--no-host-dns", dest="no_host_dns", action="store_true",
default=False,
help="Do not use DNS for hostname lookup during installation")
parser.add_option("--skip-conncheck", dest="skip_conncheck", action="store_true",
default=False, help="skip connection check to remote master")
Fix schema replication from old masters The new merged database will replicate with both the IPA and CA trees, so all DS instances (IPA and CA on the existing master, and the merged one on the replica) need to have the same schema. Dogtag does all its schema modifications online. Those are replicated normally. The basic IPA schema, however, is delivered in ldif files, which are not replicated. The files are not present on old CA DS instances. Any schema update that references objects in these files will fail. The whole 99user.ldif (i.e. changes introduced dynamically over LDAP) is replicated as a blob. If we updated the old master's CA schema dynamically during replica install, it would conflict with updates done during the installation: the one with the lower CSN would get lost. Dogtag's spawn script recently grew a new flag, 'pki_clone_replicate_schema'. Turning it off tells Dogtag to create its schema in the clone, where the IPA modifications are taking place, so that it is not overwritten by the IPA schema on replication. The patch solves the problems by: - In __spawn_instance, turning off the pki_clone_replicate_schema flag. - Providing a script to copy the IPA schema files to the CA DS instance. The script needs to be copied to old masters and run there. - At replica CA install, checking if the schema is updated, and failing if not. The --skip-schema-check option is added to ipa-{replica,ca}-install to override the check. All pre-3.1 CA servers in a domain will have to have the script run on them to avoid schema replication errors. https://fedorahosted.org/freeipa/ticket/3213
2012-10-24 03:37:16 -05:00
parser.add_option("--skip-schema-check", dest="skip_schema_check", action="store_true",
default=False, help="skip check for updated CA DS schema on the remote master")
parser.add_option("-U", "--unattended", dest="unattended", action="store_true",
default=False, help="unattended installation never prompts the user")
parser.add_option("--external-ca", dest="external_ca", action="store_true",
default=False, help="Generate a CSR to be signed by an external CA")
parser.add_option("--external-ca-type", dest="external_ca_type",
type="choice", choices=("generic", "ms-cs"),
help="Type of the external CA")
parser.add_option("--external-cert-file", dest="external_cert_files",
action="append", metavar="FILE",
help="File containing the IPA CA certificate and the external CA certificate chain")
parser.add_option("--ca-signing-algorithm", dest="ca_signing_algorithm",
type="choice",
choices=('SHA1withRSA', 'SHA256withRSA', 'SHA512withRSA'),
help="Signing algorithm of the IPA CA certificate")
options, args = parser.parse_args()
safe_options = parser.get_safe_opts(options)
if args:
filename = args[0]
if len(args) != 1:
parser.error("you must provide a file generated by "
"ipa-replica-prepare")
else:
filename = None
if options.external_ca:
if options.external_cert_files:
parser.error("You cannot specify --external-cert-file "
"together with --external-ca")
if options.external_ca_type and not options.external_ca:
parser.error(
"You cannot specify --external-ca-type without --external-ca")
return safe_options, options, filename
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
def get_dirman_password():
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
return installutils.read_password(
"Directory Manager (existing master)", confirm=False, validate=False)
def check_ca():
if not cainstance.check_port():
print "IPA requires port 8443 for PKI but it is currently in use."
sys.exit(1)
def install_dns_records(config, options):
if not bindinstance.dns_container_exists(config.master_host_name,
ipautil.realm_to_suffix(config.realm_name),
dm_password=config.dirman_password):
return
bind = bindinstance.BindInstance(dm_password=config.dirman_password)
disconnect = False
try:
if not api.Backend.ldap2.isconnected():
api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
bind_pw=config.dirman_password)
disconnect = True
bind.add_ipa_ca_dns_records(config.host_name, config.domain_name)
finally:
if api.Backend.ldap2.isconnected() and disconnect:
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
api.Backend.ldap2.disconnect()
def install_replica(safe_options, options, filename):
standard_logging_setup(log_file_name, debug=options.debug)
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
root_logger.debug('%s was invoked with argument "%s" and options: %s',
sys.argv[0], filename, safe_options)
root_logger.debug('IPA version %s', version.VENDOR_VERSION)
if not ipautil.file_exists(filename):
sys.exit("Replica file %s does not exist" % filename)
global sstore
sstore = sysrestore.StateFile(paths.SYSRESTORE)
if not dsinstance.DsInstance().is_configured():
sys.exit("IPA server is not configured on this system.\n")
api.bootstrap(in_server=True)
api.finalize()
if api.env.ra_plugin == 'selfsign':
sys.exit('A selfsign CA can not be added')
# get the directory manager password
dirman_password = options.password
if not dirman_password:
if options.unattended:
sys.exit('Directory Manager password required')
try:
dirman_password = get_dirman_password()
except KeyboardInterrupt:
sys.exit(0)
if dirman_password is None:
sys.exit("Directory Manager password required")
if not options.admin_password and not options.skip_conncheck and \
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
options.unattended:
sys.exit('admin password required')
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
config = create_replica_config(dirman_password, filename, options)
global REPLICA_INFO_TOP_DIR
REPLICA_INFO_TOP_DIR = config.top_dir
config.setup_ca = True
if not ipautil.file_exists(config.dir + "/cacert.p12"):
print 'CA cannot be installed in CA-less setup.'
sys.exit(1)
if not options.skip_conncheck:
replica_conn_check(
config.master_host_name, config.host_name, config.realm_name, True,
config.ca_ds_port, options.admin_password)
Fix schema replication from old masters The new merged database will replicate with both the IPA and CA trees, so all DS instances (IPA and CA on the existing master, and the merged one on the replica) need to have the same schema. Dogtag does all its schema modifications online. Those are replicated normally. The basic IPA schema, however, is delivered in ldif files, which are not replicated. The files are not present on old CA DS instances. Any schema update that references objects in these files will fail. The whole 99user.ldif (i.e. changes introduced dynamically over LDAP) is replicated as a blob. If we updated the old master's CA schema dynamically during replica install, it would conflict with updates done during the installation: the one with the lower CSN would get lost. Dogtag's spawn script recently grew a new flag, 'pki_clone_replicate_schema'. Turning it off tells Dogtag to create its schema in the clone, where the IPA modifications are taking place, so that it is not overwritten by the IPA schema on replication. The patch solves the problems by: - In __spawn_instance, turning off the pki_clone_replicate_schema flag. - Providing a script to copy the IPA schema files to the CA DS instance. The script needs to be copied to old masters and run there. - At replica CA install, checking if the schema is updated, and failing if not. The --skip-schema-check option is added to ipa-{replica,ca}-install to override the check. All pre-3.1 CA servers in a domain will have to have the script run on them to avoid schema replication errors. https://fedorahosted.org/freeipa/ticket/3213
2012-10-24 03:37:16 -05:00
if options.skip_schema_check:
root_logger.info("Skipping CA DS schema check")
else:
cainstance.replica_ca_install_check(config)
Fix schema replication from old masters The new merged database will replicate with both the IPA and CA trees, so all DS instances (IPA and CA on the existing master, and the merged one on the replica) need to have the same schema. Dogtag does all its schema modifications online. Those are replicated normally. The basic IPA schema, however, is delivered in ldif files, which are not replicated. The files are not present on old CA DS instances. Any schema update that references objects in these files will fail. The whole 99user.ldif (i.e. changes introduced dynamically over LDAP) is replicated as a blob. If we updated the old master's CA schema dynamically during replica install, it would conflict with updates done during the installation: the one with the lower CSN would get lost. Dogtag's spawn script recently grew a new flag, 'pki_clone_replicate_schema'. Turning it off tells Dogtag to create its schema in the clone, where the IPA modifications are taking place, so that it is not overwritten by the IPA schema on replication. The patch solves the problems by: - In __spawn_instance, turning off the pki_clone_replicate_schema flag. - Providing a script to copy the IPA schema files to the CA DS instance. The script needs to be copied to old masters and run there. - At replica CA install, checking if the schema is updated, and failing if not. The --skip-schema-check option is added to ipa-{replica,ca}-install to override the check. All pre-3.1 CA servers in a domain will have to have the script run on them to avoid schema replication errors. https://fedorahosted.org/freeipa/ticket/3213
2012-10-24 03:37:16 -05:00
check_ca()
# Configure the CA if necessary
CA = cainstance.install_replica_ca(config, postinstall=True)
# We need to ldap_enable the CA now that DS is up and running
CA.ldap_enable('CA', config.host_name, config.dirman_password,
ipautil.realm_to_suffix(config.realm_name))
# This is done within stopped_service context, which restarts CA
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
CA.enable_client_auth_to_db(CA.dogtag_constants.CS_CFG_PATH)
# Install CA DNS records
install_dns_records(config, options)
# We need to restart apache as we drop a new config file in there
services.knownservices.httpd.restart(capture_output=True)
#update dogtag version in config file
try:
fd = open(paths.IPA_DEFAULT_CONF, "a")
fd.write(
"dogtag_version=%s\n" % dogtag.install_constants.DOGTAG_VERSION)
fd.close()
except IOError, e:
print "Failed to update /etc/ipa/default.conf"
root_logger.error(str(e))
sys.exit(1)
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
def install_master(safe_options, options):
standard_logging_setup(paths.IPASERVER_CA_INSTALL_LOG, debug=options.debug)
root_logger.debug(
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
"%s was invoked with options: %s", sys.argv[0], safe_options)
root_logger.debug("IPA version %s", version.VENDOR_VERSION)
global sstore
sstore = sysrestore.StateFile(paths.SYSRESTORE)
if not dsinstance.DsInstance().is_configured():
sys.exit("IPA server is not configured on this system.\n")
api.bootstrap(in_server=True)
api.finalize()
dm_password = options.password
if not dm_password:
if options.unattended:
sys.exit('Directory Manager password required')
try:
dm_password = get_dirman_password()
except KeyboardInterrupt:
sys.exit(0)
if dm_password is None:
sys.exit("Directory Manager password required")
api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
bind_pw=dm_password)
if api.Command.ca_is_enabled()['result']:
sys.exit("CA is already installed.\n")
config = api.Command['config_show']()['result']
subject_base = config['ipacertificatesubjectbase'][0]
if options.external_ca:
if cainstance.is_step_one_done():
print ("CA is already installed.\nRun the installer with "
"--external-cert-file.")
sys.exit(1)
elif options.external_cert_files:
if not cainstance.is_step_one_done():
print ("CA is not installed yet. To install with an external CA "
"is a two-stage process.\nFirst run the installer with "
"--external-ca.")
sys.exit(1)
external_cert_file, external_ca_file = load_external_cert(
options.external_cert_files, subject_base)
if options.external_cert_files:
external = 2
elif options.external_ca:
external = 1
else:
external = 0
realm_name = api.env.realm
domain_name = api.env.domain
host_name = api.env.host
if external != 2:
check_ca()
dirname = dsinstance.config_dirname(
installutils.realm_to_serverid(realm_name))
cadb = certs.CertDB(realm_name, subject_base=subject_base)
dsdb = certs.CertDB(realm_name, nssdir=dirname, subject_base=subject_base)
for db in (cadb, dsdb):
for nickname, trust_flags in db.list_certs():
if nickname in (certdb.get_ca_nickname(realm_name),
'ipaCert',
'Signing-Cert'):
print ("Certificate with nickname %s is present in %s, "
"cannot continue." % (nickname, db.secdir))
sys.exit(1)
cert = db.get_cert_from_db(nickname)
if not cert:
continue
subject = DN(str(x509.get_subject(cert)))
if subject in (DN('CN=Certificate Authority', subject_base),
DN('CN=IPA RA', subject_base),
DN('CN=Object Signing Cert', subject_base)):
print ("Certificate with subject %s is present in %s, "
"cannot continue." % (subject, db.secdir))
sys.exit(1)
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
ca = cainstance.CAInstance(
realm_name, certs.NSS_DIR,
dogtag_constants=dogtag.install_constants)
ca.create_ra_agent_db = False
if external == 0:
ca.configure_instance(host_name, domain_name, dm_password,
dm_password, subject_base=subject_base,
ca_signing_algorithm=options.ca_signing_algorithm)
elif external == 1:
ca.configure_instance(host_name, domain_name, dm_password,
dm_password, csr_file=paths.ROOT_IPA_CSR,
subject_base=subject_base,
ca_signing_algorithm=options.ca_signing_algorithm,
ca_type=options.external_ca_type)
else:
ca.configure_instance(host_name, domain_name, dm_password,
dm_password,
cert_file=external_cert_file.name,
cert_chain_file=external_ca_file.name,
subject_base=subject_base,
ca_signing_algorithm=options.ca_signing_algorithm)
ca.stop(ca.dogtag_constants.PKI_INSTANCE_NAME)
ca.ldap_enable('CA', host_name, dm_password,
ipautil.realm_to_suffix(realm_name), ['caRenewalMaster'])
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
ca.enable_client_auth_to_db(ca.dogtag_constants.CS_CFG_PATH)
# Install CA DNS records
config = ReplicaConfig()
config.realm_name = realm_name
config.domain_name = domain_name
config.host_name = config.master_host_name = host_name
config.dirman_password = dm_password
install_dns_records(config, options)
# We need to restart apache as we drop a new config file in there
services.knownservices.httpd.restart(capture_output=True)
# Update config file
parser = RawConfigParser()
parser.read(paths.IPA_DEFAULT_CONF)
parser.set('global', 'enable_ra', 'True')
parser.set('global', 'ra_plugin', 'dogtag')
parser.set('global', 'dogtag_version',
str(ca.dogtag_constants.DOGTAG_VERSION))
with open(paths.IPA_DEFAULT_CONF, 'w') as f:
parser.write(f)
# Store the new IPA CA cert chain in DS NSS database and LDAP
cadb = certs.CertDB(realm_name, subject_base=subject_base)
dsdb = certs.CertDB(realm_name, nssdir=dirname, subject_base=subject_base)
trust_flags = dict(reversed(cadb.list_certs()))
trust_chain = cadb.find_root_cert('ipaCert')[:-1]
for nickname in trust_chain[:-1]:
cert = cadb.get_cert_from_db(nickname, pem=False)
dsdb.add_cert(cert, nickname, trust_flags[nickname])
certstore.put_ca_cert_nss(api.Backend.ldap2, api.env.basedn,
cert, nickname, trust_flags[nickname])
nickname = trust_chain[-1]
cert = cadb.get_cert_from_db(nickname, pem=False)
dsdb.add_cert(cert, nickname, trust_flags[nickname])
certstore.put_ca_cert_nss(api.Backend.ldap2, api.env.basedn,
cert, nickname, trust_flags[nickname],
config_ipa=True, config_compat=True)
# Restart DS
ds = dsinstance.DsInstance()
ds.init_info(realm_name, host_name, domain_name, dm_password, subject_base,
1101, 1100, None)
ds.restart(ds.serverid)
# Store DS CA cert in Dogtag NSS database
dogtagdb = certs.CertDB(realm_name, nssdir=ca.dogtag_constants.ALIAS_DIR)
trust_flags = dict(reversed(dsdb.list_certs()))
server_certs = dsdb.find_server_certs()
trust_chain = dsdb.find_root_cert(server_certs[0][0])[:-1]
nickname = trust_chain[-1]
cert = dsdb.get_cert_from_db(nickname)
dogtagdb.add_cert(cert, nickname, trust_flags[nickname])
ca.start(ca.dogtag_constants.PKI_INSTANCE_NAME)
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
def main():
safe_options, options, filename = parse_options()
if os.geteuid() != 0:
sys.exit("\nYou must be root to run this script.\n")
if filename is not None:
install_replica(safe_options, options, filename)
else:
install_master(safe_options, options)
fail_message = '''
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
'''
if __name__ == '__main__':
try:
with private_ccache():
installutils.run_script(main, log_file_name=log_file_name,
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
operation_name='ipa-ca-install',
fail_message=fail_message)
finally:
# always try to remove decrypted replica file
try:
if REPLICA_INFO_TOP_DIR:
shutil.rmtree(REPLICA_INFO_TOP_DIR)
except OSError:
pass