Page History
SHRINE utilizes a Java keystore to house certificates to support TLS-based https.
To Generate a New Keystore
To generate a new keystore, run the following command (on one line) within the /opt/shrine/ directory. Please use your own values wherever you see $variables.
Most importantly, ensure that $KEYSTORE_ALIAS matches the publicly-accessible hostname of the machine that will be using this keystore
After importing the signed certificates in addition to the Hub CA and HTTPS certificate, configure your Tomcat server.xml file to use the correct certificate to serve SHRINE https requests. Tomcat normally uses port 6443 to serve SHRINE.
To serve SSL find this section and change it to use the right keystore password and key alias to serve https from tomcat. Although you can use the same keyAlias to sign shrine queries and to support TLS for https most sites choose to use their own cert signed by a CA in a public cert tree. This prevents dire warnings from browsers. Follow standard procedures for serving https via TLS from tomcat. Find the example in shrine-setup/server.xml .
Code Block | ||||
---|---|---|---|---|
| ||||
$ keytool -genkeypair <!--keysize Define2048 a SSL/TLS HTTP/1.1 Connector on port 8443 This connector uses the NIO implementation that requires the JSSE style configuration. When using the APR/native implementation, the OpenSSL style configuration is required as described in the APR/native documentation --> <Connector port="6443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="/opt/shrine/shrine.keystore" keystorePass="password" keyAlias="<name_of_keystore_PrivateKeyEntry>" /> |
The URLs to the SHRINE webclient, steward, and changed in SHRINE 2.0.0. If you would like to add redirects to the old URLs, add a RewriteValve to the server.xml file and copy the shrine-setup/rewrite.config file to /opt/shrine/tomcat/conf/Catalina/localhost.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
<Valve className="org.apache.catalina.valves.rewrite.RewriteValve" />
........ |
-alias $KEYSTORE_ALIAS -dname "CN=$KEYSTORE_ALIAS, OU=$KEYSTORE_HUMAN, O=SHRINE Network, L=$KEYSTORE_CITY, S=$KEYSTORE_STATE, C=$KEYSTORE_COUNTRY" -keyalg RSA -keypass $KEYSTORE_PASSWORD -storepass $KEYSTORE_PASSWORD -keystore $KEYSTORE_FILE -storetype pkcs12 -validity 7300 |
For example, a sample site might run this:
Code Block | ||||
---|---|---|---|---|
| ||||
$ keytool -genkeypair -keysize 2048 -alias shrine-example.harvard.edu -dname "CN=shrine-example.harvard.edu, OU=SHRINE Example, O=SHRINE Network, L=Boston, S=MA, C=US" -keyalg RSA -keypass password -storepass password -keystore shrine.keystore -storetype pkcs12 -validity 7300 |
This will generate a shrine.keystore file within the /opt/shrine directory. You can then verify the creation of the keystore by running:
Code Block | ||||
---|---|---|---|---|
| ||||
$ keytool -list -keystore shrine.keystore -storepass password |
You used keytool to create a new keystore - but you have not yet created any certificates.
Using a Third-Party-Signed Certificate for Serving https Requests in Tomcat.
This wiki does not attempt to cover any vendor-specific processes or output files, because those can vary over time and across industry. It is up to each remote site that chooses this option to work with its vendor on any necessary technical details.
This guide also assumes the possibility that a site may initially opt for network CA-signed certificate, but later switch over to a third-party certificate. For all examples used in our illustration below this guide uses a fictitious remote site called shrine.example.edu
.
First generate a certificate signing request (CSR) using a private key, and to send that CSR to an SSL/TLS vendor such as InCommon or Symantec. This step can be performed using either openssl
or keytool
. The vendor will in turn generate a certificate for the requested fully-qualified domain name (FQDN), and it may provide additional certificates for its root and intermediate CAs. The remote site should work with the vendor to concatenate all certificates together into one file, so that it would be possible to trace the chain of trust from the endpoint certificate all the way back to the root CA.
Next ensure that the private key that was used to generate the CSR in a separate file. If a utility such as openssl
was used to generate the CSR, then a file containing the private key should already be present and this step is unnecessary. If, however, the site used keytool
to generate the CSR, then the following commands should be run to extract the private key from the keystore into a separate file. Execute the following commands to extract the private key into a file called private_key.pem
(the command below assumes that the keystore is called shrine.keystore
Here's a sample server.xml file (note the 'Connector port = "6443"' section):
Code Block | |||||||
---|---|---|---|---|---|---|---|
| |||||||
$ keytool -importkeystore -srckeystore shrine.keystore -srcstorepass <source_keystore_password> -srcalias shrine.example.edu -destalias shrine.example.edu -destkeystore shrine.keystore.p12 -deststoretype PKCS12 -deststorepass <destination_keystore_password>
$ openssl pkcs12 -in shrine.keystore.p12 -nodes -nocerts -out private_key.pem |
This private key should be guarded carefully. Ideal places include an encrypted disk volume and non-persistent, RAM-based disk (such as /dev/shm
in CentOS or Debian). The key can also be stored in an offline and physically secure location.
Next, upon receiving the signed certificate from the third-party CA, the remote site should then bundle the private key with the chained certificates into a PKCS12 file (.pfx
or .p12
suffix) so that SHRINE can verify the chain of trust from the endpoint certificate all the way back to the root CA. Without this trust verification, SHRINE will be unable to use the certificates as intended. For our purpose, the PKCS#12 file format is ideal because it can combine a private key with all corresponding chained certificates into a single entry in the file, and because the format is accessible by both openssl
and keytool
. In the following command (again, assuming that the private key file is called private_key.pem
), the certificates_file
contains the new endpoint certificate plus all intermediate certificates plus the root certificate, and the ca_file
contains only the intermediate certificates plus the root certificate.
Run this command to bundle the private key, the endpoint certificate, and all intermediate and root certificates into one single entry within the PKCS12 store:
Code Block | ||||
---|---|---|---|---|
| ||||
$ openssl pkcs12 -export -in <certificates_file> -inkey private_key.pem -out shrine.keystore.p12.temp -name shrine.example.edu-https -CAfile <ca_file> -chain -password pass:<your_pkcs12_file_password> |
Note here that the value of the -name
field is "shrine.example.edu-https".
The newly constructed PKCS12 file should now be imported into the original shrine.keystore
. Execute the following command, and if prompted to overwrite existing entry, answer "yes":
Code Block | ||||
---|---|---|---|---|
| ||||
$ keytool -importkeystore -srckeystore shrine.keystore.p12.temp -srcstoretype pkcs12 -srcstorepass <your_pkcs12_file_password> -srcalias shrine.example.edu-https -destkeystore shrine.keystore -deststoretype jks -deststorepass <your_destination_keystore_password> -destalias shrine.example.edu-https |
Once the import is completed, your shrine.keystore should now look like this:
Code Block | ||||
---|---|---|---|---|
| ||||
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
shrine.example.edu-https, Jul 31, 2019, PrivateKeyEntry,
Certificate fingerprint (SHA1): EF:AF:5E:D3:1A:97:AA:F2:6D:50:B8:9A:23:98:B5:2C:0C:18:C3:4B |
Next, configure the alias entry in Tomcat's server.xml
to point to the newly imported, third-party-generated certificate:
Code Block | ||||
---|---|---|---|---|
| ||||
<Connector port="6443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" <?xml version='1.0' encoding='utf-8'?> <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <!-- Note: A "Server" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/server.html --> <Server port="8005" shutdown="SHUTDOWN"> <Listener className="org.apache.catalina.startup.VersionLoggerListener" /> <!-- Security listener. Documentation at /docs/config/listeners.html <Listener className="org.apache.catalina.security.SecurityListener" /> --> <!--APR library loader. Documentation at /docs/apr.html --> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" /> <!-- Prevent memory leaks due to use of particular java/javax APIs--> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> <!-- Global JNDI resources Documentation at /docs/jndi-resources-howto.html --> <GlobalNamingResources> <!-- Editable user database that can also be used by UserDatabaseRealm to authenticate users --> <Resource name="UserDatabase" auth="Container" typekeystoreFile="org.apache.catalina.UserDatabase/opt/shrine/shrine.keystore" description keystorePass="User database that can be updated and savedxxxxxxxxxx" factorykeyAlias="orgshrine.example.edu-https"/> |
Once all configuration files have been updated, restart Tomcat. If everything has been configured properly, you should no longer see any warning messages from your browser regarding untrusted certificates when accessing your SHRINE host.
Here's a sample server.xml file (note the 'Connector port = "6443"' section):
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<?xml version='1.0' encoding='utf-8'?> <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <!-- Note: A "Server" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/server.html --> <Server port="8005" shutdown="SHUTDOWN"> <Listener className="org.apache.catalina.startup.VersionLoggerListener" /> <!-- Security listener. Documentation at /docs/config/listeners.html <Listener className="org.apache.catalina.security.SecurityListener" /> --> <!--APR library loader. Documentation at /docs/apr.html --> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" /> <!-- Prevent memory leaks due to use of particular java/javax APIs--> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> <!-- Global JNDI resources Documentation at /docs/jndi-resources-howto.html --> <GlobalNamingResources> <!-- Editable user database that can also be used byapache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /> </GlobalNamingResources> <!-- A "Service" is a collection of one or more "Connectors" that share a single "Container" Note: A "Service" is not itself a "Container", so you may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/service.html --> <Service name="Catalina"> <!--The connectors can use a shared executor, you can define one or more named thread pools--> <!-- <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="150" minSpareThreads="4"/> --> <!-- A "Connector" represents an endpoint by which requests are received and responses are returned. Documentation at : Java HTTP Connector: /docs/config/http.html (blocking & non-blocking) Java AJP Connector: /docs/config/ajp.html APR (HTTP/AJP) Connector: /docs/apr.html Define a non-SSL/TLS HTTP/1.1 Connector on port 8080 --> <Connector port="6060" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="6443" /> <!-- A "Connector" using the shared thread pool--> <!-- <Connector executor="tomcatThreadPool" UserDatabaseRealm to authenticate users port="8080" protocol="HTTP/1.1 --> <Resource name="UserDatabase" auth="Container" connectionTimeouttype="20000org.apache.catalina.UserDatabase" redirectPortdescription="8443" /> --> User database that can be updated and saved" <!-- Define a SSL/TLS HTTP/1.1 Connector on port 8443 factory="org.apache.catalina.users.MemoryUserDatabaseFactory" This connector uses the NIO implementation that requires the JSSE style configuration. When using the APR/native implementation, the pathname="conf/tomcat-users.xml" /> </GlobalNamingResources> <!-- A "Service" is a collection of one or more "Connectors" that share a single "Container" Note: OpenSSL styleA configuration"Service" is requirednot asitself described in the APR/nativea "Container", so you documentation --> <Connector port="6443" protocol="org.apache.coyote.http11.Http11NioProtocol" may not define subcomponents such as "Valves" at this level. Documentation at /docs/config/service.html maxThreads="150" SSLEnabled="true" scheme="https" secure="true"--> <Service name="Catalina"> <!--The connectors can use a shared executor, you can define one clientAuth="false" sslProtocol="TLS" or more named thread pools--> <!-- <Executor keystoreFile="/opt/shrine/shrine.keystorename="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="150" minSpareThreads="4"/> --> <!-- A keystorePass="passwordConnector" represents an endpoint by which requests are received keyAlias="<name_of_keystore_PrivateKeyEntry>" /> and responses are returned. Documentation at : <!-- Define an AJPJava 1.3HTTP Connector on port 8009 --> : /docs/config/http.html (blocking & non-blocking) <Connector port="6009" protocol="AJP/1.3" redirectPort="8443" /> <!-- An Engine represents the entry point (within Catalina) that processes Java AJP Connector: /docs/config/ajp.html APR (HTTP/AJP) Connector: /docs/apr.html every request. The Engine implementation for Tomcat stand aloneDefine a non-SSL/TLS HTTP/1.1 Connector on port 8080 --> <Connector port="6060" protocol="HTTP/1.1" analyzes the HTTP headers included with the request, and passes themconnectionTimeout="20000" on to the appropriate Host (virtual host). redirectPort="6443" /> <!-- A "Connector" using the Documentationshared at /docs/config/engine.html thread pool--> <!-- You should set jvmRoute to support load-balancing via AJP ie : <Connector executor="tomcatThreadPool" <Engine name="Catalina" defaultHostport="localhost8080" jvmRouteprotocol="jvm1HTTP/1.1"> --> <Engine name="Catalina" defaultHost="localhost"> connectionTimeout="20000" <!--For clustering, please take a look at documentation at:redirectPort="8443" /> --> <!-- Define a SSL/docs/cluster-howto.html (simple how to)TLS HTTP/1.1 Connector on port 8443 /docs/config/cluster.html (reference documentation) --> <!-- This connector uses the NIO implementation that requires the JSSE <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/> --> style configuration. When using the APR/native implementation, the <!-- Use the LockOutRealmOpenSSL tostyle preventconfiguration attemptsis torequired guessas userdescribed passwords in the APR/native via a brute-force attackdocumentation --> <Connector <Realm classNameport="6443" protocol="org.apache.catalinacoyote.realmhttp11.LockOutRealmHttp11NioProtocol"> <!-- This Realm uses the UserDatabase configured in the global JNDImaxThreads="150" SSLEnabled="true" scheme="https" secure="true" resources under the key "UserDatabase". Any editsclientAuth="false" sslProtocol="TLS" that are performed against this UserDatabase are immediately keystoreFile="/opt/shrine/shrine.keystore" keystorePass="password" available for use by the Realm. --> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" keyAlias="<name_of_keystore_PrivateKeyEntry>" /> <!-- Define an AJP 1.3 Connector on port resourceName="UserDatabase"/8009 --> </Realm> <Host name="localhost" appBase="webapps" <Connector port="6009" protocol="AJP/1.3" redirectPort="8443" /> <!-- An Engine represents the entry point (within unpackWARs="true" autoDeploy="true"> Catalina) that processes <Valve className="org.apache.catalina.valves.rewrite.RewriteValve" /> every request. The Engine implementation <!-- SingleSignOn valve, share authentication between web applications for Tomcat stand alone analyzes the HTTP headers included with the request, and passes them on to the appropriate Host (virtual host). Documentation at: /docs/config/valveengine.html --> <!-- You should set jvmRoute to support <Valve className="org.apache.catalina.authenticator.SingleSignOn" /load-balancing via AJP ie : <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1"> --> <Engine --name="Catalina" defaultHost="localhost"> <!--For Accessclustering, logplease processestake alla example. look at documentation at: Documentation at: /docs/config/valvecluster-howto.html (simple how to) Note: The pattern used is equivalent to using pattern="common" --> /docs/config/cluster.html (reference documentation) --> <!-- <Cluster <Valve classNameclassName="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t "%r" %s %b" /> </Host> </Engine> </Service> </Server> |
Info | ||
---|---|---|
| ||
This step is optional for remote sites. |
By default, our recommendation for a typical remote site is to have it submit a Certificate Signing Request (CSR) to the certificate authority (CA) of the SHRINE network to which they are joining. The CA will in turn generate a new certificate for the downstream site, and we will return that certificate, the hub certificate, and the CA certificate of the tier back to the downstream site. The site will then import the certificates into their shrine keystore file, and configure their shrine.conf
and server.xml
to point to the alias entry in the keystore that corresponds to the site.
A typical keystore after importing all the certs in would look like this (assuming that the downstream site is called "shrine.example.edu
"):
Code Block | ||||
---|---|---|---|---|
| ||||
Keystore type: jks
Keystore provider: SUN
Your keystore contains 3 entries
shrine.example.edu, Oct 31, 2018, PrivateKeyEntry,
Certificate fingerprint (SHA1): 26:0B:FE:98:21:BA:C8:5A:A5:F5:35:79:8E:81:1A:E9:F4:3B:FF:56
shrine-act-test-ca, Jul 31, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 13:4D:B5:5C:E3:48:A0:7B:9B:20:22:8B:0B:C1:BE:DD:B9:E4:1B:AD
shrine-act-test.hms.harvard.edu, Jul 31, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 52:82:A0:6D:D1:48:B2:EA:BB:2C:58:BD:E5:C7:3B:21:75:2B:46:F6 |
shrine.conf
contains a block like this:
Code Block | ||||
---|---|---|---|---|
| ||||
keystore {
file = "/opt/shrine/shrine.keystore"
password = "xxxxxx"
privateKeyAlias = "shrine.example.edu"
keyStoreType = "JKS"
caCertAliases = ["shrine-act-test-ca"]
} |
And server.xml
will contain a block like this:
Code Block | ||||
---|---|---|---|---|
| ||||
<Connector port="6443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/opt/shrine/shrine.keystore"
keystorePass="xxxxxx"
keyAlias="shrine.example.edu"/> |
When using the above approach a web browser attempting to access a shrine host configured in this way will generate a warning. The browser will not trust the CA because none of the CAs are public. Consequently, any certificate that the CA signs is not trusted by the browser. While the browser can be configured to ignore the warning and the CA can be manually imported into the browser's trust store, some downstream sites may opt for a more elegant approach. Using a third-party-signed certificate eliminates the warnings from the web browser; the root and intermediate CAs are already trusted by the browser.
Using a Third-Party-Signed Certificate for Serving https Requests in Tomcat.
A third-party certificate does not replace the network CA-signed certificate; the network CA-signed certificate is still required for signing all application-specific messages. This wiki does not attempt to cover any vendor-specific processes or output files, because those can vary over time and across industry. It is up to each remote site that chooses this option to work with its vendor on any necessary technical details.
This guide also assumes the possibility that a site may initially opt for network CA-signed certificate, but later switch over to a third-party certificate. For all examples used in our illustration below this guide uses a fictitious remote site called shrine.example.edu
.
The first step for the remote site is to generate a certificate signing request (CSR) using a private key, and to send that CSR to an SSL/TLS vendor such as InCommon and Symantec. This step can be performed using either openssl
or keytool
. The vendor will in turn generate a certificate for the requested fully-qualified domain name (FQDN), and it may provide additional certificates for its root and intermediate CAs. The remote site should work with the vendor to concatenate all certificates together into one file, so that it would be possible to trace the chain of trust from the endpoint certificate all the way back to the root CA.
The next step is to ensure that the private key that was used to generate the CSR is in a separate file. If a utility such as openssl
was used to generate the CSR, then a file containing the private key should already be present and this step is unnecessary. If, however, the site used keytool
to generate the CSR, then the following commands should be run to extract the private key from the keystore into a separate file. Execute the following commands to extract the private key into a file called private_key.pem
(the command below assumes that the keystore is called shrine.keystore
):
Code Block | ||||
---|---|---|---|---|
| ||||
$ keytool -importkeystore -srckeystore shrine.keystore -srcstorepass <source_keystore_password> -srcalias shrine.example.edu -destalias shrine.example.edu -destkeystore shrine.keystore.p12 -deststoretype PKCS12 -deststorepass <destination_keystore_password>
$ openssl pkcs12 -in shrine.keystore.p12 -nodes -nocerts -out private_key.pem |
This private key should be guarded carefully. Ideal places include an encrypted disk volume and non-persistent, RAM-based disk (such as /dev/shm
in CentOS or Debian). The key can also be stored in an offline and physically secure location.
Next, upon receiving the signed certificate from the third-party CA, the remote site should then bundle the private key with the chained certificates into a PKCS12 file (.pfx
or .p12
suffix) so that SHRINE can verify the chain of trust from the endpoint certificate all the way back to the root CA. Without this trust verification, SHRINE will be unable to use the certificates as intended. For our purpose, the PKCS#12 file format is ideal because it can combine a private key with all corresponding chained certificates into a single entry in the file, and because the format is accessible by both openssl
and keytool
. In the following command (again, assuming that the private key file is called private_key.pem
), the certificates_file
contains the new endpoint certificate plus all intermediate certificates plus the root certificate, and the ca_file
contains only the intermediate certificates plus the root certificate. Run this command to bundle the private key, the endpoint certificate, and all intermediate and root certificates into one single entry within the PKCS12 store:
Code Block | ||||
---|---|---|---|---|
| ||||
$ openssl pkcs12 -export -in <certificates_file> -inkey private_key.pem -out shrine.keystore.p12.temp -name shrine.example.edu-https -CAfile <ca_file> -chain -password pass:<your_pkcs12_file_password> |
Note here that the value of the -name
field is "shrine.example.edu-https". The reason is that we will eventually be importing this entire entry back into the main Java keystore where another entry called shrine.example.edu
already exists. Recalling our earlier discussion about the purposes of certificates, we note that shrine.example.edu
entry is responsible for application message signing, while shrine.example.edu-https
entry is responsible for web browser encryption. Therefore two distinct keystore entries are necessary.
The newly constructed PKCS12 file should now be imported into the original shrine.keystore
. Execute the following command, and if prompted to overwrite existing entry, answer "yes":
Code Block | ||||
---|---|---|---|---|
| ||||
$ keytool -importkeystore -srckeystore shrine.keystore.p12.temp -srcstoretype pkcs12 -srcstorepass <your_pkcs12_file_password> -srcalias shrine.example.edu-https -destkeystore shrine.keystore -deststoretype jks -deststorepass <your_destination_keystore_password> -destalias shrine.example.edu-https |
Once the import is completed, your shrine.keystore should now look like this:
Code Block | ||||
---|---|---|---|---|
| ||||
Keystore type: jks
Keystore provider: SUN
Your keystore contains 4 entries
shrine.example.edu, Oct 31, 2018, PrivateKeyEntry,
Certificate fingerprint (SHA1): 26:0B:FE:98:21:BA:C8:5A:A5:F5:35:79:8E:81:1A:E9:F4:3B:FF:56
shrine.example.edu-https, Jul 31, 2019, PrivateKeyEntry,
Certificate fingerprint (SHA1): EF:AF:5E:D3:1A:97:AA:F2:6D:50:B8:9A:23:98:B5:2C:0C:18:C3:4B
shrine-act-test-ca, Jul 31, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 13:4D:B5:5C:E3:48:A0:7B:9B:20:22:8B:0B:C1:BE:DD:B9:E4:1B:AD
shrine-act-test.hms.harvard.edu, Jul 31, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 52:82:A0:6D:D1:48:B2:EA:BB:2C:58:BD:E5:C7:3B:21:75:2B:46:F6 |
Notice that there are now two (2) entries associated with shrine.example.edu: the original one continues to be used for application signing, and we will configure the "-https
" entry for use by Tomcat to encrypt web browser traffic.
Next, configure the alias entry in Tomcat's server.xml
to point to the newly imported, third-party-generated certificate:
Code Block | ||||
---|---|---|---|---|
| ||||
<Connector port="6443" protocol="org.apache.coyote.http11.Http11NioProtocol".apache.catalina.ha.tcp.SimpleTcpCluster"/> --> <!-- Use the LockOutRealm to prevent attempts to guess user passwords via a brute-force attack --> <Realm className="org.apache.catalina.realm.LockOutRealm"> <!-- This Realm uses the UserDatabase configured in the global JNDI resources under the key "UserDatabase". Any edits that are performed against this UserDatabase are immediately available for use by the Realm. --> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/> </Realm> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Valve className="org.apache.catalina.valves.rewrite.RewriteValve" /> <!-- SingleSignOn valve, share authentication between web applications Documentation at: /docs/config/valve.html --> <!-- <Valve className="org.apache.catalina.authenticator.SingleSignOn" /> --> <!-- Access log processes all example. Documentation at: maxThreads="150" SSLEnabled="true" scheme="https" secure="true" /docs/config/valve.html Note: The pattern used is equivalent to using pattern="common" --> <Valve clientAuthclassName="falseorg.apache.catalina.valves.AccessLogValve" sslProtocoldirectory="TLSlogs" keystoreFileprefix="localhost_access_log" suffix="/opt/shrine/shrine.keystore.txt" keystorePass="xxxxxxxxxx" pattern="%h %l %u %t "%r" %s %b" /> </Host> keyAlias="shrine.example.edu-https"/> |
...
</Engine>
</Service>
</Server> |