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:

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/CDA access using TLS.

  1. Create a Keystore File for Your Tomcat Installation
  2. Import a Signed Certificate into the Keystore (Optional)
  3. Configure the Tomcat Connection
  4. Test Access to Your AWI Instance
  5. Create/Request/Import Certificate for Automic Continuous Delivery Automation on IIS (Internet Information Services)
  6. Change Binding of the Default Website
  7. Access Automic Continuous Delivery Automation
  8. Export the Certificate
  9. Add the IIS Certificate to the Java Trust Store
  10. Update the AWI Plugin Configuration
  11. Modify the Endpoint Settings in the web.config File (if Necessary)
  12. Detect the CDA Server url and Set it Where Required

Create a Keystore File for Your Tomcat Installation

  1. Open a command prompt with administrator rights and change the path to the Tomcat configuration directory (TOMCAT_HOME/conf/).

  2. 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.

  3. 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.

  1. Use the following command to import a chain certificate or root certificate (if available) into your keystore:
  2. "%JAVA_HOME%\bin\keytool" -import -alias root -keystore tomcat-keystore.jks -trustcacerts -file <filename_of_the_chain_certificate>

     

  3. Import the certificate with this command:
  4. "%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.

  5. To import an existing certificate signed by your own Certificate Authority (CA) into a PKCS12 keystore using OpenSSL, execute a command like this:
  6. openssl pkcs12 -export -in mycert.crt -inkey mykey.key
        -out mycert.p12 -name tomcat -CAfile myCA.crt
        -caname root -chain

Configure the Tomcat Connection

  1. Open the server.xml file located in the configuration directory of your Tomcat instance.
  2. Add and save the following connector configuration in your configuration file:
  3. <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.

  4. Restart your Tomcat instance to apply the changes.

Test Access to Your AWI Instance

You can now access the Automic Web Interface using a secure connection.

Create/Request/Import Certificate for Automic Continuous Delivery Automation on IIS (Internet Information Services)

  1. Open the Internet Information Services (IIS) Manager.
  2. Select your server in the explorer and double-click the Server Certificates icon.

Do one of the following:

Change Binding of the Default Website

  1. Go back to the IIS Manager Explorer and select the Web Site running the CDA application on your Server.
  2. Click Bindings... on the Edit Site section of the Actions side panel.
  3. 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.

  4. 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

Export the Certificate

Export the currently used certificate:

  1. Open the Internet Information Services (IIS) Manager.
  2. Select your server and the Web Site running the CDA application.
  3. Open the Bindings... dialog again.
  4. Select the https row and click Edit...

  5. Click View... and navigate to the Details tab.

  6. Click Copy to File... . The Certificate Export Wizard is displayed.
  7. Click Next >
  8. Select No, do not export the private key and click Next.
  9. Select DER encoded binary X.509 (.CER) and click Next.
  10. Enter a destination folder to store your certificate.

  11. Click Finish to complete the wizard.

Add the IIS Certificate to the Java Trust Store

  1. 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.

  2. 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

  1. 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).

  2. 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:

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: