7:02 p.m.
Please perform an initial code review on the attached patches (only
applicable for RHCS 8.1 on RHEL 5).
The following two patches address:
* 'pkicreate' now does three types of port configuration:
o IP Port Separation
o Port Separation
o Shared Ports (deprecated)
* security manager issue was fixed
* new security domain schema is complete
* the security domain has been implementedto comply with this new schema
* generated a multi-host CA complete with an SSL Server Certificate
containing SAN information (utilizes profile framework)
* generated a multi-host KRA complete with an SSL Server Certificate
containing SAN information (utilizes name/value pairs passed in via
the enrollment URL which are processed via the profile framework)
* addressed 'TokenAuthenticate' SSL_ForceHandshake issue by utilizing
DNSName instead of DirectoryName attributes in the SSL Server
certificate SAN extensions
* applied the checkIP() feature described in 'Bugzilla Bug #708075
-Clone installation does not work over NAT'
* applied substitution of raw IP addresses from 'pkicreate' into the
'server.xml' to support the new IP Port Separation mode
Development test info:
* pki-ip-host (installation host - RHEL 5.9 x86_64)
o pki-ca-agent (CA agent interface - virtual IP)
o pki-ca-ee (CA EE interface- virtual IP)
o pki-ca-ee-ca (CA EE clientauth interface- virtual IP)
o pki-ca-admin (CA admin interface- virtual IP)
o pki-kra-agent (KRA agent interface- virtual IP)
o pki-kra-ee (KRA EE interface- virtual IP)
o pki-kra-admin (KRA admin interface- virtual IP)
* pki-rhel6 (RHDS 9.1 - RHEL 6.3 x86_64 which uses a different domain)
Thus far, only the following tests have been run against these patches:
* successfully tested regression case of CA and KRA installed using
Port Separation
* successfully tested sanity case of CA and KRA installed using IP
Port Separation
* successfully tested mixed mode deployment case of a CA installed
using Port Separation and a KRA installed using IP Port Separation
* successfully tested mixed mode deployment case of a CA installed
using IP Port Separation and a KRA installed using Port Separation
* successfully tested miscellaneous case of specifying a CA with four
virtual IPs (none of which belonged to the host that the server was
being installed upon) using IP Port Separation
* successfully tested miscellaneous case of CA and KRA installed using
IP Port Separation utilizing unique IP addresses for each interface
(none of which specified the installation host IP), but specifying
the same HTTP/HTTPS port numbers (e. g. - 19080/19443) and unique
ports for Tomcat (9701/10701)
o NOTE: I managed to successfully test this case with SELinux in
Enforcing mode -- this is because the only ports that would be
labeled are the Tomcat ports which exist on the installation
machine (which do not in this case, as they are the default
cases for pki_ca_port_t and pki_kra_port_t). In this test case,
since none of the interfaces refer to the installation machine
IP, none of these ports are labeled by SELinux. The 'pkicreate'
executable enforces unique <hostname:port> entries. While a
second instance (e. g. - KRA) could be installed re-using the
<hostname:port> entries specified (e. g. - CA), the two
instances could not be started simultaneously due to an
inability to bind (java.net.BindException: Address already in
use) - see 'netstat -a | grep <host>' or 'netstat -a | grep
<port>'.
* successfully tested miscellaneous case of installing a CA using IP
Port Separation which was configured using a customized SAN
'serverCert.profile' which included two additional SAN entries on
top of the entries computed for IP Port Separation
The following issues are still actively being addressed:
* failure of java security manager to allow server to start when
specifying non-installation host ports 80/443 (SELinux in permissive
mode) results in (java.net.BindException: Permission denied:80) -
(i. e. - see
http://www.jvmhost.com/articles/java-net-bindexception-permisssion-denied...)
* failure of pkisilent to successfully configure a PKI instance
* reported concerns regarding the ability to install/configure an
RA/TPS instance which uses the existing code changes requiredfor
interaction with the revised security domain