Securing Access with HTTPS
TLS allows web browsers and REST API clients to communicate over a secured connection because data is encrypted. By enforcing authentication, TLS also ensures that the site origin is what it claims to be.
Plug-ins and Backend Services
If you are using plug-ins that implement HTTPS to establish a secure communication with the backend services, make sure that Tomcat or the JVM you are using are configured to trust the certificates installed on the backend services.
Use the certificates issued by a Certificate Authority that the JVM trusts by default.
If you need to use self-signed certificates, configure Tomcat or JVM to trust the certificates by adding them to one of the following truststores:
-
Default JVM truststore
-
A different truststore
Configure Tomcat to use a different truststore. For more information on the truststore parameters, refer to the product documentation of the Tomcat connector configuration.
As of version 11.2, the ssl.properties configuration file is no longer supported. If you upgrade from an earlier version, you must reconfigure your secure communication.
Overview
Follow these steps to secure AWI
- Create a Keystore File for Your Tomcat Installation
- Import a Signed Certificate into the Keystore (Optional)
- Configure the Tomcat Connection
- Test Access to Your AWI Instance
- Create/Request/Import Certificate for Automic Continuous Delivery Automation on IIS (Internet Information Services)
- Change Binding of the Default Website
- Access Automic Continuous Delivery Automation
- Export the Certificate
- Add the IIS Certificate to the Java Trust Store
- Update the AWI Plugin Configuration
- Modify the Endpoint Settings in the web.config File (if Necessary)
- Detect the CDA Server url and Set it Where Required
Create a Keystore File for Your Tomcat Installation
-
Open a command prompt with administrator rights and change the path to the Tomcat configuration directory (TOMCAT_HOME/conf/).
-
Create a keystore file with a self-signed certificate using the following command.
Warning! SHA-1 certificates are considered to be unsafe by modern browsers. Use SHA-256 instead.
"%JAVA_HOME%\bin\keytool" -genkey -alias tomcat -keyalg RSA -keystore tomcat-keystore.jks -storepass myTomcatKeystorePassword
This will result in the output as shown below (status after complete editing).
The cursor jumps to the first line you can enter your values in. After each entry confirm with the Return key to jump to the next line.
What is your first and last name?
[Unknown]: localhost
What is the name of your organizational unit?
[Unknown]: YOUR_UNIT
What is the name of your organization?
[Unknown]: YOUR_ORGANIZATION
What is the name of your City or Locality?
[Unknown]: YOUR_CITY
What is the name of your State or Province?
[Unknown]: YOUR_STATE
What is the two-letter country code for this unit?
[Unknown]: AT
Is CN=localhost, OU=YOUR_UNIT, O=YOUR_ORGANIZATION, L=YOUR_CITY, ST=YOUR_STATE, C=AT correct?
[no]: YES
Enter key password for <tomcat>
(RETURN if same as keystore password):
Use the hostname / domain of your AWI instance as your first and last name ((localhost)
in this example).
This command creates a new keystore file named tomcat-keystore.jks
protected with the password myTomcatKeystorePassword
located in the configuration directory. The keystore contains a self-signed certificate for your AWI instance.
Import a Signed Certificate into the Keystore (Optional)
Skip this step if you are using the self-signed certificate created in the previous step.
- Use the following command to import a chain certificate or root certificate (if available) into your keystore:
- Import the certificate with this command:
-
To import an existing certificate signed by your own Certificate Authority (CA) into a
PKCS12
keystore using OpenSSL, execute a command like this:
"%JAVA_HOME%\bin\keytool" -import -alias root -keystore tomcat-keystore.jks -trustcacerts -file <filename_of_the_chain_certificate>
"%JAVA_HOME%\bin\keytool" -import -alias tomcat -keystore tomcat-keystore.jks -file <your_certificate_filename>
Tomcat only supports keys and certificates in the JKS
, PKCS11
or PKCS12
format.
openssl pkcs12 -export -in mycert.crt -inkey mykey.key
-out mycert.p12 -name tomcat -CAfile myCA.crt
-caname root -chain
Configure the Tomcat Connection
- Open the
server.xml
file located in the configuration directory of your Tomcat instance. - Add and save the following connector configuration in your configuration file:
- Restart your Tomcat instance to apply the changes.
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
keyAlias="tomcat" keystoreFile="conf\tomcat-keystore.jks" keystorePass="myTomcatKeystorePassword"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
For the keystorePass
parameter, enter the password of the tomcat-keystore.jks
.
Test Access to Your AWI Instance
You can now access the Automic Web Interface using a secure connection.
-
Use a URL (
https://YOUR_DOMAIN:8443/awi/
).
Example:https://localhost:8443/awi/
. -
If you are using a self-signed certificate you may receive a warning that the connection is untrusted because it is not possible to verify the identity. You can only avoid this warning if you are using signed certificates by a trusted certificate authority. The connection encryption is the same as with a self-signed certificate. Confirm that you want to use the self-signed certificate on the dialog that pops up.
Create/Request/Import Certificate for Automic Continuous Delivery Automation on IIS (Internet Information Services)
- Open the Internet Information Services (IIS) Manager.
- Select your server in the explorer and double-click the Server Certificates icon.
Do one of the following:
-
If you do not have a certificate yet, create a self-signed certificate by clicking Create Self-Signed Certificate... in the Actions side panel.
Tip: Use localhost as friendly name and select Web Hosting as certificate store (if available).
-
If you already have a valid TLS certificate, click Import... in the Actions side panel.
- Create a certificate request by clicking Create Certificate Request in the Actions side panel.
Populate the fields on the Distinguished Name Properties page of the wizard.
Make sure the common name matches the server name.
- On the Cryptographic Service Provider Properties page, select one of the providers from the Cryptographic service provider drop-down list.
- From the Bit length drop-down list, select a bit length that can be used by the provider. (Default values: RSA = 1024, DH= 512), and click Next.
- On the File Name page, type or select a file name, and click Finish.
- Send the certificate request to a public CA.
- Download the certificate and import it (double-click the Server Certificates action and click the Import... action in the side panel).
- Right-click the certificate, set a friendly name and select the option Enable all purposes for this certificate.
- In the Actions menu, click Complete Certificate Request to open the Complete Request Certificate wizard.
- On the Specify Certificate Authority Response page, browse to the
.cer
certificate file, select it and click Open. - Enter a friendly name and click OK.
Tip: Use localhost as friendly name and select Web Hosting as certificate store (if available).
Change Binding of the Default Website
- Go back to the IIS Manager Explorer and select the Web Site running the CDA application on your Server.
- Click Bindings... on the Edit Site section of the Actions side panel.
- Do one of the following:
- Select the https row and click Edit...
- If you do not see this row, create a new row by clicking Add....
Use the following configuration:
Type: https
IP address: all Unassigned
Port: 443 (or something else)
SSL certificate: Select your Self-Signed Certificate or imported certificate created during the previous steps.
-
Go to the SSL Settings of your website. Click the Require SSL checkbox and select the Ignore option for client certificates, and click Apply.
Access Automic Continuous Delivery Automation
-
You can now access the Automic Web Interface via a secure connection by using https://YOUR_DOMAIN:443/ara/.
Example:https://localhost:443/ara/) -
If you are using a self-signed certificate you may receive a warning that the connection is untrusted, because is not possible to verify the identity. You can only avoid this warning if you are using signed certificates by a trusted authority. However the connection is encrypted in the same way as using a signed certificate. You have to confirm that you want to use the self-signed certificate.
Export the currently used certificate:
- Open the Internet Information Services (IIS) Manager.
- Select your server and the Web Site running the CDA application.
- Open the Bindings... dialog again.
-
Select the https row and click Edit...
-
Click View... and navigate to the Details tab.
- Click Copy to File... . The Certificate Export Wizard is displayed.
- Click Next >
- Select No, do not export the private key and click Next.
- Select DER encoded binary X.509 (.CER) and click Next.
-
Enter a destination folder to store your certificate.
-
Click Finish to complete the wizard.
Add the IIS Certificate to the Java Trust Store
-
To ensure proper communication between AWI and CDA, import the certificate to the Java Trust Store. Your Java Trust Store is located in the /lib/security/ folder of your Java Runtime Installation.
-
Add the previously exported certificate to the cacerts Trust Store and trust it by using the following command as Administrator:
> "%JAVA_HOME%\bin\keytool" -import -v -trustcacerts -alias <hostname> -file <your_certificate.cer> -keystore cacerts -storepass changeit
Update the AWI Plugin Configuration
-
Currently AWI uses a non-encrypted connection to the CDA server. Update the connection properties to use a full-encrypted connection: open the connection.properties file which is located in the /config/webui-plugin-bond/ folder of your AWI installation (eg. TOMCAT_HOME/webapp/awi).
-
Update the url property to the new HTTPS URL and restart the tomcat web server.
Modify the Endpoint Settings in the web.config File (if Necessary)
Depending on your setup you may have to uncomment the following two sections in the web.config
file (Automic\Release.Manager\WebUI\web.config):
<endpoint address="" binding="basicHttpBinding" contract="Ventum.Bond2.Services.Deployments.IDeploymentService"bindingConfiguration="DeploymentServiceBinding">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
and
<endpoint address="" binding="basicHttpBinding"contract="Ventum.Bond2.Services.Integrations.IIntegrationService" bindingConfiguration="DeploymentServiceBinding">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
For more information, see Configuring the Web Application - Web.Config.
Detect the CDA Server url and Set it Where Required
You can retrieve the correct URL that the CDA server is working from the CDA DeploymentService page. Enter the path pointing to the DeploymentService in your browser.
Example: https://myARAServer/service/DeploymentService.svc
.
A page resembling the screenshot below will be displayed:
The yellow box marks the CDA sever URL you entered (as part of the complete URL for accessing the Deployment Service page). The green boxes highlight the part of the URL that must be set in the following configuration files:
-
customer.config
(Automic\Release.Manager\WebUI\customer.config):UC4Deployment.CallbackUrl
parameter. For more information, see Configuring the Web Application - Customer.Config<add key="UC4Deployment.CallbackUrl" value="https://araServer.global.net:443/ARA" />
If you are using ONE Installer, you can find the
customer.config
file inC:\Automic\Release.Manager\Utilities\DataMigrator
. -
connection.properties
: parameter urlurl=https://araServer.global.net:443/ARA
Example:C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\AWI\WEB-INF\autoinstall
).If you are using ONE Installer, you can find the
connection.properties
file inC:\Automic\External.Resources\apache-tomcat-7.0.81\webapps\awi\config\webui-plugin-bond\connection.properties
.
For more information, see Deployment Service.
Important! Make sure that AWI / Automic Continuous Delivery Automation is always called with fully qualified URLs that match the certificate. Using different URLs (for example: a short well-known URL) might lead to errors due to security restrictions.
Common Errors
If Release Automation is not displayed in AWI anymore, you may find the following error message in your Tomcat log files:
com.uc4.ecc.plugins.bond.exception.BondNotAvaiableException: Check failed. cannot create sso token Error requesting Deployment Manager Single-Sign-On endpoint
at com.uc4.ecc.plugins.bond.entrypoint.BondPluginInstance.checkBondAvailability(BondPluginInstance.java:90) ~[na:na]
at com.uc4.ecc.plugins.bond.entrypoint.BondPluginInstance.start(BondPluginInstance.java:55) ~[na:na]
at com.uc4.ecc.framework.entrypoint.navigation.PluginInstantiator.startPluginInstance(PluginInstantiator.java:288) [ecc-framework-entrypoint.jar:na]
at com.uc4.ecc.framework.entrypoint.navigation.PluginInstantiator.createPluginsAndPerspectives(PluginInstantiator.java:163) [ecc-framework-entrypoint.jar:na]
at com.uc4.ecc.framework.entrypoint.navigation.PluginInstantiator.instantiatePlugins(PluginInstantiator.java:131) [ecc-framework-entrypoint.jar:na]
at com.uc4.ecc.framework.entrypoint.login.AE.AECredentialsPresenter.login(AECredentialsPresenter.java:219) [ecc-framework-entrypoint.jar:na]
at com.uc4.ecc.framework.entrypoint.login.AE.AECredentialsPresenter.access$200(AECredentialsPresenter.java:43) [ecc-framework-entrypoint.jar:na]
at com.uc4.ecc.framework.entrypoint.login.AE.AECredentialsPresenter$2.load(AECredentialsPresenter.java:162) [ecc-framework-entrypoint.jar:na]
at com.uc4.ecc.framework.entrypoint.login.AE.AECredentialsPresenter$2.load(AECredentialsPresenter.java:155) [ecc-framework-entrypoint.jar:na]
at com.uc4.ecc.framework.core.async.BaseRequestCoordinator$1$1.call(BaseRequestCoordinator.java:214) [ecc-framework-core.jar:na]
at com.uc4.ecc.framework.core.pool.ContextAwareExecutorService$CallableImplementation.call(ContextAwareExecutorService.java:72) [ecc-framework-core.jar:na]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_45]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_45]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
Caused by: com.uc4.ecc.plugins.bond.exception.SsoException: Error requesting Deployment Manager Single-Sign-On endpoint
at com.uc4.ecc.plugins.bond.backend.sso.BondSsoService.createToken(BondSsoService.java:76) ~[na:na]
at com.uc4.ecc.plugins.bond.entrypoint.BondPluginInstance.checkBondAvailability(BondPluginInstance.java:82) ~[na:na]
... 14 common frames omitted
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[na:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937) ~[na:1.8.0_45]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) ~[na:1.8.0_45]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) ~[na:1.8.0_45]
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478) ~[na:1.8.0_45]
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212) ~[na:1.8.0_45]
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) ~[na:1.8.0_45]
at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) ~[na:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050) ~[na:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363) ~[na:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391) ~[na:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375) ~[na:1.8.0_45]
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:535) ~[na:na]
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:403) ~[na:na]
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) ~[na:na]
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304) ~[na:na]
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) ~[na:na]
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) ~[na:na]
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) ~[na:na]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) ~[na:na]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) ~[na:na]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) ~[na:na]
at com.uc4.ecc.plugins.bond.backend.sso.BondSsoService.createToken(BondSsoService.java:74) ~[na:na]
... 15 common frames omitted
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387) ~[na:1.8.0_45]
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292) ~[na:1.8.0_45]
at sun.security.validator.Validator.validate(Validator.java:260) ~[na:1.8.0_45]
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[na:1.8.0_45]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229) ~[na:1.8.0_45]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124) ~[na:1.8.0_45]
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460) ~[na:1.8.0_45]
... 33 common frames omitted
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145) ~[na:1.8.0_45]
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131) ~[na:1.8.0_45]
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) ~[na:1.8.0_45]
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382) ~[na:1.8.0_45]
... 39 common frames omitted
Check that you have added the self-signed IIS certificate correctly and that you have used the right Java trust store.
See also: