IP Port Separation CURRENTLY UNDER CONSTRUCTION …#
Overview#
Definition#
There are three types of IP Port Separation:
IP Port Separation consists of specifying individual interfaces for a PKI subsystem in which all of the IP addresses, generally specified as hostnames represented by their fully qualified domain names (FQDNs), are combined with their associated ports to form unique addresses.
IP Separation is a special case of IP port separation in which a user specifies unique IP addresses but utilizes one port for the non-secure EE connection, another port for the non-secure Tomcat connection, and one common port for all of the secure ports. If desired by the user, the installation host (e. g. - pki-ip-host.example.com) may be specified as one of the unique IP addresses (e. g. - the admin hostname) in order to have its port automatically labelled by SELinux.
Port Separation is a special case of IP port separation in which a user specifies all IP addresses as the same FQDN and specifies unique ports for the non-secure EE connection, the non-secure Tomcat connection, and unique ports for each of the secure ports. If the installation hostname is specified as the FQDN, then the only difference between port separation defined in this manner and the legacy manner described below is that for the IP port separation method, the PKI subsystem SSL server certificate will contain a single subject alternative name extension which contains the installation host.
Earlier versions of Dogtag separated CA, KRA, OCSP, and TKS interfaces by a single common IP address and unique port number for each interface [://:]:
\ ```http://pki-ip-host.example.com:9180 <http://pki-ip-host.example.com:9180>`__\ ```https://pki-ip-host.example.com:9443 <https://pki-ip-host.example.com:9443>`__\ ```https://pki-ip-host.example.com:9444 <https://pki-ip-host.example.com:9444>`__\ ```https://pki-ip-host.example.com:9445 <https://pki-ip-host.example.com:9445>`__\ ```https://pki-ip-host.example.com:9446 <https://pki-ip-host.example.com:9446>`__Dogtag 10 introduced the concept of a PKI instance which consists of a single Tomcat instance which may contain a single java-based Tomcat CA, KRA, OCSP, TKS, and/or TPS subsystem within this common PKI instance, and was redesigned to separate these PKI instances by merely using a single common IP address with either an individual unsecure HTTP port number or an individual secure HTTPS port number and a URL path [//::/]:
\ ```http://pki-ip-host.example.com:8080/ca/ee/ca <http://pki-ip-host.example.com:8080/ca/ee/ca>`__\ ```https://pki-ip-host.example.com:8443/ca/agent/ca <https://pki-ip-host.example.com:8443/ca/agent/ca>`__\ ```https://pki-ip-host.example.com:8443/ca/ee/ca <https://pki-ip-host.example.com:8443/ca/ee/ca>`__\ ```https://pki-ip-host.example.com:8443/ca/admin/ca <https://pki-ip-host.example.com:8443/ca/admin/ca>`__\ ```https://pki-ip-host.example.com:8443/ca/eeca/ca <https://pki-ip-host.example.com:8443/ca/eeca/ca>`__An IP separated Dogtag 10 PKI instance would still be of the form [//::/], and would resemble something like the following:
\ ```http://pki-ca-ee.example.com:8080/ca/ee/ca <http://pki-ca-ee.example.com:8080/ca/ee/ca>`__\ ```https://pki-ca-agent.example.com:8443/ca/agent/ca <https://pki-ca-agent.example.com:8443/ca/agent/ca>`__\ ```https://pki-ca-ee.example.com:8443/ca/ee/ca <https://pki-ca-ee.example.com:8443/ca/ee/ca>`__\ ```https://pki-ca-admin.example.com:8443/ca/admin/ca <https://pki-ca-admin.example.com:8443/ca/admin/ca>`__\ ```https://pki-ca-ee.example.com:8443/ca/eeca/ca <https://pki-ca-ee.example.com:8443/ca/eeca/ca>`__Requirements#
Associated Bugs and Tickets#
Use Cases#
Hostname:
pki-ip-host.example.com
HTTP Port:
8080
HTTPS Port:
8443
Virtual IP Hostnames:
pki-ca-admin.example.com
pki-ca-agent.example.com
pki-ca-ee.example.com
pki-kra-admin.example.com
pki-kra-agent.example.com
pki-kra-ee.example.com
Case I: No IP Separation#
Example of a single PKI instance containing a CA and a KRA utilizing no IP Port Separation:
PKI Subsystem |
PKI Connection Type |
PKI Interface |
PKI URL |
|---|---|---|---|
CA |
unsecure |
End-Entity |
http://pki-ip- host.example.co m:8080/ca/ee/ca |
CA |
secure |
End-Entity |
https://pki-ip- host.example.co m:8443/ca/ee/ca |
CA |
secure |
Agent |
htt ps://pki-ip-hos t.example.com:8 443/ca/agent/ca |
CA |
secure |
Administrator |
htt ps://pki-ip-hos t.example.com:8 443/ca/admin/ca |
KRA |
unsecure |
End-Entity |
h ttp://pki-ip-ho st.example.com: 8080/kra/ee/kra |
KRA |
secure |
End-Entity |
ht tps://pki-ip-ho st.example.com: 8443/kra/ee/kra |
KRA |
secure |
Agent |
https ://pki-ip-host. example.com:844 3/kra/agent/kra |
KRA |
secure |
Administrator |
https ://pki-ip-host. example.com:844 3/kra/admin/kra |
Case II: Partial IP Separation#
Example of a single PKI instance containing a CA and a KRA utilizing partial IP Port Separation (e. g. - for all End-Entity and Agent URLs but not for Admin URLs):
PKI Subsystem |
PKI Connection Type |
PKI Interface |
PKI URL |
|---|---|---|---|
CA |
unsecure |
End-Entity |
http://pki-c a-ee.example.co m:8080/ca/ee/ca |
CA |
secure |
End-Entity |
https://pki-c a-ee.example.co m:8443/ca/ee/ca |
CA |
secure |
Agent |
http s://pki-ca-agen t.example.com:8 443/ca/agent/ca |
CA |
secure |
Administrator |
htt ps://pki-ip-hos t.example.com:8 443/ca/admin/ca |
KRA |
unsecure |
End-Entity |
http://pki-kra- ee.example.com: 8080/kra/ee/kra |
KRA |
secure |
End-Entity |
h ttps://pki-kra- ee.example.com: 8443/kra/ee/kra |
KRA |
secure |
Agent |
https:/ /pki-kra-agent. example.com:844 3/kra/agent/kra |
KRA |
secure |
Administrator |
https ://pki-ip-host. example.com:844 3/kra/admin/kra |
Case III: Complete IP Separation#
Example of a single PKI instance containing a CA and a KRA utilizing complete IP Port Separation:
PKI Subsystem |
PKI Connection Type |
PKI Interface |
PKI URL |
|---|---|---|---|
CA |
unsecure |
End-Entity |
http://pki-c a-ee.example.co m:8080/ca/ee/ca |
CA |
secure |
End-Entity |
https://pki-c a-ee.example.co m:8443/ca/ee/ca |
CA |
secure |
Agent |
http s://pki-ca-agen t.example.com:8 443/ca/agent/ca |
CA |
secure |
Administrator |
http s://pki-ca-admi n.example.com:8 443/ca/admin/ca |
KRA |
unsecure |
End-Entity |
http://pki-kra- ee.example.com: 8080/kra/ee/kra |
KRA |
secure |
End-Entity |
h ttps://pki-kra- ee.example.com: 8443/kra/ee/kra |
KRA |
secure |
Agent |
https:/ /pki-kra-agent. example.com:844 3/kra/agent/kra |
KRA |
secure |
Administrator |
https:/ /pki-kra-admin. example.com:844 3/kra/admin/kra |
Operating System Platforms and Architectures#
This IP port separation design shall be designed, developed and tested on the following platforms:
Fedora 20 [i686 (32-bit)]
Fedora 20 [x86_64 (64-bit)]
Design#
Design Considerations#
Criteria#
Any PKI subsystem utilizing IP port separation must meet the following criteria:
PKI Subsystem#
Dogtag 10 consists of the following five java-based Tomcat 7 PKI subsystems†† (hereafter referred to as simply a PKI subsystem):
Certificate Authority (CA)
Data Recovery Manager (DRM) [a.k.a. - Key Recovery Authority (KRA)]
Online Certificate Status Protocol (OCSP) Manager
Token Key Service (TKS)
Token Process System††† (TPS)
†† - |
Dogtag 10 also contains an Apache-based PKI subsystem called a Registration Authority (RA) to which IP port separation does not apply. |
††† - |
Some versions of Dogtag 10 may also contain a legacy Apache-based PKI subsystem called TPS to which IP port separation does not apply. For the purposes of this design, TPS always refers to the java-based Tomcat 7 TPS. |
Each PKI subsystem must be installed on a single installation host.
PKI Interfaces#
Each PKI subsystem installed on the installation host must specify unique [://:/] interfaces:
PKI In terface |
PKI Con nection P rotocol |
CA Path |
DRM Path |
OCSP Path |
TKS Path |
TPS Path |
|---|---|---|---|---|---|---|
End -Entity |
http |
c a/ee/ca |
kra /ee/kra |
ocsp/ ee/ocsp |
tks /ee/tks |
|
End -Entity |
https |
c a/ee/ca |
kra /ee/kra |
ocsp/ ee/ocsp |
tks /ee/tks |
|
O perator |
https |
tp s/opera tor/tps |
||||
Agent |
https |
ca/a gent/ca |
kra/ag ent/kra |
o csp/age nt/ocsp |
tks/ag ent/tks |
tps/ag ent/tps |
Admini strator |
https |
ca/a dmin/ca |
kra/ad min/kra |
o csp/adm in/ocsp |
tks/ad min/tks |
tps/ad min/tps |
For each CA subsystem, a unique [://:/] combination must be specified for the agent, end-entity (EE), admin, and end-entity client authentication (EECA) interfaces
For each DRM, OCSP, or TKS subsystem, a unique [://:/] combination must be specified for the agent, EE, and admin interfaces
For each TPS subsystem, a unique [://:/] combination must be specified for the agent, operator, and admin interfaces
PKI Ports#
Each PKI subsystem must specify a port for the non-secure HTTP EE port, the non-secure HTTP Tomcat port, and for each separated secure HTTPS port:
For each PKI subsystem, although each separated secure port does not need to be unique (e. g. - each “secure” port could be specified to be the same port number such as 8443), each [://:/] interface must still be unique.
For each PKI subsystem, the non-secure HTTP Tomcat port must be different from the non-secure HTTP EE port which must be different from all of the secure HTTPS ports.
For a CA subsystem, a port must be specified for each of the HTTP Tomcat, HTTP EE, HTTPS agent, HTTPS EE, HTTPS admin, and HTTPS EECA interfaces.
For a DRM, OCSP, or TKS subsystem, a port must be specified for each of the HTTP Tomcat, HTTP EE, HTTPS agent, HTTPS EE, and HTTPS admin interfaces.
For a TPS subsystem, a port must be specified for each of the HTTP Tomcat, HTTPS agent, HTTPS operator, and HTTPS admin interfaces.
PKI Hostnames#
Each PKI subsystem must specify a hostname for each individual PKI interface which meet the following criteria:
For each PKI subsystem, although each designated hostname does not need to be unique, each [://:/] interface must still be unique.
For each PKI subsystem, the installation hostname shall be utilized as the hostname associated with the non-secure HTTP Tomcat port.
For each PKI subsystem, the hostname designated as the EE hostname shall be utilized for both the non-secure HTTP EE port as well as the secure HTTPS EE port.
For a CA subsystem, a hostname must be specified for each of the agent, EE, admin, and EECA interfaces.
For a DRM, OCSP, or TKS subsystem, a hostname must be specified for each of the agent, EE, and admin interfaces.
For a TPS subsystem, a hostname must be specified for each of the agent, operator, and admin interfaces.
PKI Instances#
Each Dogtag 10 Tomcat 7-based instance (hereafter referred to as simply a PKI instance) must consist of at least one of these PKI subsystems, and may consist of any combination of these PKI subsystems with the limitation of up to one of each single type of PKI subsystem per PKI instance. For example:
CA
DRM
CA, OCSP
CA, DRM, OCSP, TKS, TPS
etc.
Each individual PKI instance is currently defined by the following characteristics:
a single IP address
a unique PKI instance name associated with this IP address
an unsecure http port
a secure https port
a unique Tomcat 7 AJP port
a unique Tomcat 7 server port used for shutting down the PKI instance
differentiation of an individual PKI subsystem type inside of a PKI instance via a unique URL path
For example, given three PKI instances installed on the same machine (hostname) where:
the first IP instance (e. g. - pki-tomcat) contains a CA subsystem which utilizes no IP separation of its PKI interfaces,
the second IP instance (e. g. - pki-tomcat-1) contains a CA subsystem that contains partial IP separation of its PKI interfaces, and
the third PKI instance (e. g. - pki-tomcat-2) contains a CA subsystem and a KRA subsystem utilizing complete IP separation of all of its PKI interfaces,
the following interfaces may be differentiated from each other by unique [://:/] on one or more of these interfaces:
PKI H ostname |
PKI I nstance Name (first) |
PKI Su bsystem |
PKI Con nection Type |
PKI In terface |
PKI Path |
PKI URL |
|---|---|---|---|---|---|---|
pk i-ip-ho st.exam ple.com |
pki -tomcat |
CA |
u nsecure |
End -Entity |
c a/ee/ca |
ht tp://pk i-ip-ho st.exam ple.com :8080/c a/ee/ca |
pk i-ip-ho st.exam ple.com |
pki -tomcat |
CA |
secure |
End -Entity |
c a/ee/ca |
htt ps://pk i-ip-ho st.exam ple.com :8443/c a/ee/ca |
pk i-ip-ho st.exam ple.com |
pki -tomcat |
CA |
secure |
Agent |
ca/a gent/ca |
https: //pki-i p-host. example .com:84 43/ca/a gent/ca |
pk i-ip-ho st.exam ple.com |
pki -tomcat |
CA |
secure |
Admini strator |
ca/a dmin/ca |
https: //pki-i p-host. example .com:84 43/ca/a dmin/ca |
PKI H ostname |
PKI I nstance Name ( second) |
PKI Su bsystem |
PKI Con nection Type |
PKI In terface |
PKI Path |
PKI URL |
pk i-ip-ho st.exam ple.com |
pki-t omcat-1 |
CA |
u nsecure |
End -Entity |
c a/ee/ca |
h ttp://p ki-ca-e e.examp le.com: 18080/c a/ee/ca |
pk i-ip-ho st.exam ple.com |
pki-t omcat-1 |
CA |
secure |
End -Entity |
c a/ee/ca |
ht tps://p ki-ca-e e.examp le.com: 18443/c a/ee/ca |
pk i-ip-ho st.exam ple.com |
pki-t omcat-1 |
CA |
secure |
Agent |
ca/a gent/ca |
h ttps:// pki-ca- agent.e xample. com:184 43/ca/a gent/ca |
pk i-ip-ho st.exam ple.com |
pki-t omcat-1 |
CA |
secure |
Admini strator |
ca/a dmin/ca |
https:/ /pki-ip -host.e xample. com:184 43/ca/a dmin/ca |
PKI H ostname |
PKI I nstance Name (third) |
PKI Su bsystem |
PKI Con nection Type |
PKI In terface |
PKI Path |
PKI URL |
pk i-ip-ho st.exam ple.com |
pki-t omcat-2 |
CA |
u nsecure |
End -Entity |
c a/ee/ca |
h ttp://p ki-ca-e e.examp le.com: 28080/c a/ee/ca |
pk i-ip-ho st.exam ple.com |
pki-t omcat-2 |
CA |
secure |
End -Entity |
c a/ee/ca |
ht tps://p ki-ca-e e.examp le.com: 28443/c a/ee/ca |
pk i-ip-ho st.exam ple.com |
pki-t omcat-2 |
CA |
secure |
Agent |
ca/a gent/ca |
h ttps:// pki-ca- agent.e xample. com:284 43/ca/a gent/ca |
pk i-ip-ho st.exam ple.com |
pki-t omcat-2 |
CA |
secure |
Admini strator |
ca/a dmin/ca |
h ttps:// pki-ca- admin.e xample. com:284 43/ca/a dmin/ca |
pk i-ip-ho st.exam ple.com |
pki-t omcat-2 |
DRM |
u nsecure |
End -Entity |
kra /ee/kra |
http ://pki- kra-ee. example .com:28 080/kra /ee/kra |
pk i-ip-ho st.exam ple.com |
pki-t omcat-2 |
DRM |
secure |
End -Entity |
kra /ee/kra |
https ://pki- kra-ee. example .com:28 443/kra /ee/kra |
pk i-ip-ho st.exam ple.com |
pki-t omcat-2 |
DRM |
secure |
Agent |
kra/ag ent/kra |
http s://pki -kra-ag ent.exa mple.co m:28443 /kra/ag ent/kra |
pk i-ip-ho st.exam ple.com |
pki-t omcat-2 |
DRM |
secure |
Admini strator |
kra/ad min/kra |
http s://pki -kra-ad min.exa mple.co m:28443 /kra/ad min/kra |
High-Level Design#
‘default.cfg’#
The following variables will be added to the following [SECTION]s:
‘pkislots.cfg’#
The following variables will be added to the [Tomcat] section:
‘pkispawn’#
The following slot variables will be added to the ‘pkiparser.py’ file:
The ‘pki_hostname’ variable will still be computed, and its value will be used as a default value for each specified ‘default.cfg’ [SECTION] as defined above.
However, the usage of the ‘pki_hostname’ and ‘hostname’ variables within the ‘pkihelper.py’ and ‘pkiparser.py’ files will need to be reviewed and changed as necessary.
‘server.xml’#
The ‘PKI Status Definition’ section will be altered to reference the new individual hostnames:
<!-- DO NOT REMOVE - Begin PKI Status Definitions -->
<!-- CA Status Definitions -->
<!--
Unsecure URL = http://[PKI_EE_HOSTNAME]:[PKI_UNSECURE_PORT]/ca/ee/ca
Secure Agent URL = https://[PKI_AGENT_HOSTNAME]:[PKI_AGENT_SECURE_PORT]/ca/agent/ca
Secure EE URL = https://[PKI_EE_HOSTNAME]:[PKI_EE_SECURE_PORT]/ca/ee/ca
Secure Admin URL = https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/ca/services
EE Client Auth URL = https://[PKI_EE_HOSTNAME]:[PKI_EE_SECURE_CLIENT_AUTH_PORT]/ca/eeca/ca
PKI Console Command = pkiconsole https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/ca
Tomcat Port = [TOMCAT_SERVER_PORT] (for shutdown)
-->
<!-- KRA Status Definitions -->
<!--
Unsecure URL = http://[PKI_EE_HOSTNAME]:[PKI_UNSECURE_PORT]/kra/ee/kra
Secure Agent URL = https://[PKI_AGENT_HOSTNAME]:[PKI_AGENT_SECURE_PORT]/kra/agent/kra
Secure EE URL = https://[PKI_EE_HOSTNAME]:[PKI_EE_SECURE_PORT]/kra/ee/kra
Secure Admin URL = https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/kra/services
PKI Console Command = pkiconsole https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/kra
Tomcat Port = [TOMCAT_SERVER_PORT] (for shutdown)
-->
<!-- OCSP Status Definitions -->
<!--
Unsecure URL = http://[PKI_EE_HOSTNAME]:[PKI_UNSECURE_PORT]/ocsp/ee/ocsp
Secure Agent URL = https://[PKI_AGENT_HOSTNAME]:[PKI_AGENT_SECURE_PORT]/ocsp/agent/ocsp
Secure EE URL = https://[PKI_EE_HOSTNAME]:[PKI_EE_SECURE_PORT]/ocsp/ee/ocsp
Secure Admin URL = https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/ocsp/services
PKI Console Command = pkiconsole https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/ocsp
Tomcat Port = [TOMCAT_SERVER_PORT] (for shutdown)
-->
<!-- TKS Status Definitions -->
<!--
Unsecure URL = http://[PKI_EE_HOSTNAME]:[PKI_UNSECURE_PORT]/tks/ee/tks
Secure Agent URL = https://[PKI_AGENT_HOSTNAME]:[PKI_AGENT_SECURE_PORT]/tks/agent/tks
Secure EE URL = https://[PKI_EE_HOSTNAME]:[PKI_EE_SECURE_PORT]/tks/ee/tks
Secure Admin URL = https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/tks/services
PKI Console Command = pkiconsole https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/tks
Tomcat Port = [TOMCAT_SERVER_PORT] (for shutdown)
-->
<!-- TPS Status Definitions -->
<!--
Unsecure URL = http://[PKI_OPERATOR_HOSTNAME]:[PKI_UNSECURE_PORT]/tps/operator/tps
Secure Agent URL = https://[PKI_AGENT_HOSTNAME]:[PKI_AGENT_SECURE_PORT]/tps/agent/tps
Secure EE URL = https://[PKI_OPERATOR_HOSTNAME]:[PKI_EE_SECURE_PORT]/tps/operator/tps
Secure Admin URL = https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/tps/services
PKI Console Command = pkiconsole https://[PKI_ADMIN_HOSTNAME]:[PKI_ADMIN_SECURE_PORT]/tps
Tomcat Port = [TOMCAT_SERVER_PORT] (for shutdown)
-->
<!-- DO NOT REMOVE - End PKI Status Definitions -->
TBD
PKI Security Domain#
Apply the following changes to the security domain:
Create the ‘AgentHost’, ‘EEHost’, ‘AdminHost’, ‘EEClientAuthHost’, and ‘OperatorHost’ attributes as syntax type 1.3.6.1.4.1.1466.115.121.1.15 (Directory String)
Add ‘AgentHost’, ‘EEHost’, ‘AdminHost’, ‘EEClientAuthHost’, and ‘OperatorHost’ to the MAY section of ‘pkiSubsystem-oid’ objectClass
SSL Server Certificates#
The subject name of each PKI subsystem’s SSL server certificate shall always reference the FQDN of the EE hostname. For example:
`` Subject: CN=pki-ca-ee.example.com,OU=pki-ca,O=Example Domain``
Additionally, whenever any PKI subsystem is installed using any type of IP port separation, a PKI subsystem’s SSL server certificate shall also always contain a subject alternative name extension which will contain a ‘DNSName’ entry for each unique hostname specified during the pkispawn installation process. The first value will always reflect the DNS name of the machine referenced in the certificate’s subject name. For example:
TBD
Low-Level Design#
Implementation#
‘’’IMPORTANT: |
Although this design document is entitled IP Port Separation, at least initially, for the purposes of implementing this feature for Dogtag 10, only IP Separation will be implemented. |
Virtual IPs#
No matter which port configuration mode is chosen, the PKI subsystem will be installed in its totality on a single installation host (i. e. - any given CA subsystem which specifies separate virtual IP interfaces for HTTP EE, HTTPS agent, HTTPS EE, HTTPS admin, and HTTPS EE clientauth must be installed on a single host which contains the Tomcat server; individual PKI subsystems such as a second CA, a DRM, etc. may reside on the same or different hosts provided that each PKI interface is unique across all of the PKI subsystems).
In order to gain the flexibility provided by IP port separation, it is first necessary to establish IP addresses that will be utilized for each of the desired interfaces on this installation host. The following IP addresses and FQDN hostnames are provided as examples:
After setting up an installation host and establishing its network, create virtual IP network addresses on the same NIC which will provide the ability to specify separate IP addresses for each desired PKI interface.
IPTables#
When a user chooses to utilize a proxy (e. g. - in order to utilize ports less than 1024), the user may want to create something similar to the following scripts:
\ **``reset_iptables``**\ ``:The following set_pki_proxy_iptables script is an example of what would be written for a CA using a proxy:
\ **``set_pki_proxy_iptables``**\ ``:\ ```http://pki-ca-ee.example.com:80 <http://pki-ca-ee.example.com:80>`__`` –>``\ ```http://pki-ca-ee.example.com:8080 <http://pki-ca-ee.example.com:8080>`__\ ```https://pki-ca-agent.example.com:443 <https://pki-ca-agent.example.com:443>`__`` –>``\ ```https://pki-ca-agent.example.com:8443 <https://pki-ca-agent.example.com:8443>`__\ ```https://pki-ca-ee.example.com:443 <https://pki-ca-ee.example.com:443>`__`` –>``\ ```https://pki-ca-ee.example.com:8443 <https://pki-ca-ee.example.com:8443>`__\ ```https://pki-ca-admin.example.com:443 <https://pki-ca-admin.example.com:443>`__`` –>``\ ```https://pki-ca-admin.example.com:8443 <https://pki-ca-admin.example.com:8443>`__\ ```https://pki-ca-ee-ca.example.com:443 <https://pki-ca-ee-ca.example.com:443>`__`` –>``\ ```https://pki-ca-ee-ca.example.com:8443 <https://pki-ca-ee-ca.example.com:8443>`__NOTE: ** If an Apache server is used as a proxy, iptables must be configured and the user must set ‘pki_enable_proxy=True’ prior to running **pkispawn.
Instance Separation#
Dogtag 10 currently allows separation of multiple PKI instances containing the same subsystem to co-exist on the same machine as long as they are separated by some sort of IP Port Separation.
One potential implementation methodology to separate instances of the same subsystem on the same machine may utilize the notion of Linux Containers:
Interface Separation#
Each PKI subsystem contained within a PKI instance contains multiple distinct interfaces (e. g. - a CA contains an unsecure End-Entity interface, a secure End-Entity interface, an Agent interface, and an Administration interface).
Currently, regardless of what form of IP Port Separation is chosen, access to these interfaces may be separated via ACLs based upon the deployment policy:
End-Entity interfaces require no certificate for client authentication whereas the Agent and Administration interfaces require a common certificate for client authentication (default)
End-Entity interfaces require no certificate for client authentication whereas the Agent interface and Administration interfaces require separate distinct certificates for client authentication
Additionally, different forms of IP Port Separation could be utilized to provide interface separation based upon user roles (i. e. - distinct URLs to different interfaces within a common PKI subsystem existing inside a given PKI instance).
It has been proposed that one means of accomplishing this may be through the use of one or more of the various Tomcat 7 server.xml configurations using the slot substitution method available via pkispawn:
Apache Tomcat 7 Configuration Directives for ‘server.xml’
-
Remote Address Valve (Raw IP Addresses)
Remote Host Valve (DNS Hostnames – requires HTTP Connector sets “enableLookups=true”)
Remote IP Valve (may be especially useful when a proxy or load balancer is utilized)
and/or through the use of one or more of the various Tomcat 7 web.xml configurations using the slot substitution method available via pkispawn:
Major configuration options and enablement#
The default values contained in this file can be easily overriden through the use of an overlay configuration file during invocation of ‘pkispawn -s -f ‘.
For example:
Cloning#
TBD
Updates and Upgrades#
TBD
Tests#
TBD
Dependencies#
TBD
Packages#
TBD
External Impact#
TBD
History#
**ORIGINAL DESIGN DATE: ** November 8, 2013