[hier eingeben] · see below all snap-ins of the computer account (local machine). to import a...

[Hier eingeben]

INHALT

Prerequisites .............................................................................................................. 2

1.1 Microsoft Internet Information Services (IIS) ........................................... 2

1.2 Java and Apache Tomcat ............................................................................ 2

Certificates ................................................................................................................. 3

Import a certificate to the Microsoft Windows key store ................................... 4

Import a certificate to the Java key store/trust store .......................................... 6

1.3 Using an own Java key store/trust store .................................................. 7

Microsoft Internet Information Services (IIS) ........................................................ 8

1.4 Configuration of https using IIS 6 ............................................................. 8

1.5 Configuration of https using IIS 7 .......................................................... 11

Server Configurator ............................................................................................... 15

Control Center Agent ............................................................................................ 17

Web Applications ................................................................................................... 18

Apache Tomcat ....................................................................................................... 19

Servicetrace Robotic Solutions | https Config Guide

© Servicetrace GmbH 2018

Servicetrace® Robotic Solution https Configuration Guide | 2

PREREQUISITES

To use transport security (https over SSL) for Servicetrace Web Applica-

tions and Web Services the following prerequisites must be given at

customer side.

1.1 Microsoft Internet Information Services (IIS)

The Internet Information Services (IIS) has to be configured to use trans-

port security – i.e. https over SSL. Thus a binding to https (standard port

443) must exist for the website (e.g. Default Website), which hosts the

Servicetrace Web Applications / Web Services.

If the IIS is not addressable with its hostname but rather with a full qua-

lified domain name, this domain name has to be specified as Host Header.

The host header has to be configured as hostname within the https bin-

ding (see Chapter 1.5.1).

1.2 Java and Apache Tomcat

During the https configuration for the IIS a certificate is used. This cer-

tificate should be signed by at least one Root Certificate Authority (CA).

Additionally several Intermediate CAs may exist within the certification

path. Thus a chain of trust is built.


The certificates of this root and Intermediate CAs have to be known by

the Apache Tomcat as well. For this reason, these certificates have to be

included in the system-wide Java key store (cacerts) of the Java Runtime

Environment (JRE), which executes the Apache Tomcat. If the Root and

Intermediate CAs are well known and trusted Certificate Authorities,

their certificates should already be contained in the system-wide Java key

store as of installation. Thus no further steps are required. If the Root

CA and eventually existing Intermediate CAs are not known by the Java

Runtime, they have to be imported to the Java system key store (cacerts).

See chapter 0 for a detailed description of how to configure the Java

system key store.

CERTIFICATES

To enable transport security (https over SSL) for the Microsoft Internet

Information Services (IIS) and the Apache Tomcat a certificate is required,

which is signed by a trusted Root Certificate Authority (CA) like VeriSign,

Thawte, etc. Thus a Chain of Trust exists. Normally a host accepts certi-

ficates, if it trusts the certificate itself or if it trusts one of the Root and

Intermediate CA along the chain of trust.

Certificates of many well known and trusted Certificate Authorities are

automatically installed with the Operating System and the Java system

key store (cacerts). Thus certificates signed by these Certificate Autho-

rities are trusted automatically. There is no need to deploy these certifi-

cates to key stores.

Servicetrace recommends not to use self-signed certificates because self-signed certificates are not signed by a trusted Root CA as known by the Operating System and the Java system key store . Thus self-signed certificates need to be deployed to each robot separatally to establish a https communication with the Control Center server.

Comparing certificates If you need to check whether two certificates are identical, always check their fingerprints. Same certificates got identical names and fingerprints!


IMPORT A CERTIFICATE TO THE MICROSOFT

WINDOWS KEY STORE

The Microsoft Windows Operating System has several key stores con-

taining certificates of many Root Certificate Authorities. To see all regis-

tered certificates of the respective Windows host the Microsoft Manage-

ment Console (MMC) can be used. Here a user can add the snap-in called

“Certificates”.

While adding this snap-in the user selects whether certificates registered

for the current user, service accounts or computer accounts are dis-

played.


See below all snap-ins of the computer account (local machine).

To import a X.509 certificate to a key store, the MMC snap-in may be

used. Right-click at the key store used for the import and select All Tasks

> Import. A dialog opens to select the respective X.509 certificate file

(e.g. .cer file) from the local file system.


IMPORT A CERTIFICATE TO THE JAVA KEY

STORE/TRUST STORE

Because Java is independent of the Operating System, Java manages its

own key store / trust store. Like Windows, Java supports chaining during

the verification of certificates. Thus a certificate will be verified by ve-

rifying the respective intermediate certificates up to a root certificate

created by a Root Certificate Authority (Root CA). Such key stores (files)

may be found in these directories:

System-wide Root CA certificates: C:\Program Files\Java\jre6\lib\security\cacerts

User-specific certificates: $USERPROFILE$\.keystore

The user independent system key store cacerts contains certificates of

many trusted Root CAs and will be installed with the Java Runtime En-

vironment (JRE). The key store .keystore within a user’s home directory

is the default key store of a specific user (which does not exist by

default).

The management of certificates is done by the command line application

keytool.exe, which is included within the bin directory of the JRE. With

the aid of this tool, certificates can be created, imported, exported, etc.

Furthermore a list of certificates within a key store can be displayed in

human readable format. For example, the following command lists all

certificates of the trusted Root CAs within the cacerts key store of the

JRE.

keytool -list -keystore “C:\Program Files\Java\jre6\lib\security\ca-

certs” –v

The default password of the cacerts key store is changeit.

The command to insert a Root CA’s (Intermediate CA’s) certificate to the

key store cacerts looks like

keytool -importcert -alias <alias_name> -keystore “C:\Program Fi-

les\Java\jre6\lib\security\cacerts” -file <certificate.cer>

During a Java update the key store cacerts will be reset! Thus it is the user’s responsibility to import the necessary certificates (e.g. Root CA and Intermediate CA certificates) after the Java update.


1.3 Using an own Java key store/trust store

You may use an own key store to avoid Java / caecerts update issues.

You may copy the system key store cacerts or create a new key store. In

both cases, the required certificates (e.g. Root CA and Intermediate CA

certificates) have to be imported to your key store.

Use the following command to create a new key store. If the specified

key store file does not exist, the import command creates it automati-

cally.

keytool -importcert -alias <alias_name> -keystore <path_to_new_key-

store_file> -file <certificate.cer>

Command to import a Root (Intermediate) CA’s certificate to a key store:

keytool -importcert -alias <alias_name> -keystore <path_to_key-

store_file> -file <certificate.cer>

An own key store / trust store is not subject of security updates! Thus the owner is responsible for the key store’s security.

After the creation of an own key store/trust store the Apache Tomcat

Server has to be configured to use the respective key store during the

start of the Java VM. To do this, the own key store/trust store has to be

configured with the aid of the Java system property javax.net.ssl.trust-

Store. System properties may be specified to the Java VM as follows

-Djavax.net.ssl.trustStore=<Path to own key store/trust

store>

The screenshot below shows the Configure Tomcat Tool. Within the tab

“Java” the field “Java Options” may be used to specify Java system pro-

perties.


MICROSOFT INTERNET INFORMATION SERVICES

(IIS)

This chapter describes the steps necessary to configure https over SSL

within the IIS 6 and IIS 7, respectively. First of all, please note the follo-

wing hints.

To use a certificate in conjunction with the Internet Information Ser-vices (IIS) the certificate must include a private key. This is done with a so called “Personal Information Exchange” (PFX) file, which combines a certificate and its private key. A PFX file is imported the same way as a normal certificate.

The CN name of a certificate and the domain name within the respec-tive https-URL must be equal! Thus the certificate used at the side of the Microsoft Internet Informa-tion Services (IIS) must be created with the respective host name as CN name.

As mentioned above, to enable the IIS for https a Personal Information

Exchange (PFX) file is needed. Please take care to import the PFX file to

the Windows Local Machine’s key store (see chapter 0 for a detailed

description). After the certificate’s import and registration, respectively,

the certificate can be used for the https configuration within the Internet

Information Services. The following two chapters explain the steps,

which has to be performed in IIS 6 or IIS 7.

1.4 Configuration of https using IIS 6

The certificate included within the Personal Information Exchange (PFX)

file can be used to enable https support of the IIS 6. To assign a certifi-

cate to the respective web site open the IIS Manager (e.g. by using i-

netmgr.exe). Right-click the web site, which hosts the respective web

page and select “Properties” to open the properties dialog.


Within this dialog, open the tab called “Directory Security”.

The assignment of the certificate is done within the “Secure communica-

tions” group. Use the button “Server Certificates” to open the import dia-

log. Follow the wizard steps. The kind of certificate import has to be

answered with “Assign an existing certificate”.


The next wizard step shows the certificates ready to be assigned to the

IIS. Here the respective certificate has to be selected. If no SSL port was

specified so far, the next wizard steps require the specification of such

a port. The SSL standard port 443 is preconfigured. These steps are ski-

pped, if a SSL port was already specified.

Close the “Properties” dialog with the “OK” button and reopen the “Pro-

perties” dialog.

Now, make sure that the SSL port is set within the tab “Web Site”. Also

verify the existence of at least one SSL identity by clicking the button

“Advanced…” at the tab “Web Site”.

Now, IIS 6 is ready to be used with https.


1.5 Configuration of https using IIS 7

The certificate included within the Personal Information Exchange (PFX)

file can be used to enable https support of the IIS 7. To assign a certifi-

cate to the respective web site, open the IIS Manager (e.g. by using i-

netmgr.exe). Left-click the IIS 7, which hosts the respective web site and

select the feature “Server Certificates”.

After the feature opened, select the action “Import…” to import the Per-

sonal Information Exchange (PFX) file.


Within the import dialog please activate the option “Allow this certificate

to be exported”. To import the certificate click the “OK” button. The newly

added certificate appears in the list of “Server Certificates”.

Now, the added server certificate can be used to add and configure new

https bindings. Left-click the respective Web Site and perform the action

“Edit Site – Bindings”.


The dialog “Site Bindings” appears. Within this dialog select the “Add…”

button and add a site binding of type “https” by using the previously

added SSL certificate.

If the web site ’s domain name is different to the host name the IIS 7 is running at, do as follows: This is done with a so called “Personal Information Exchange” (PFX) file, which combines a certificate and its private key. A PFX file is imported the same way as a normal certificate.

Configuration of a Host Header

On demand, the Control Center Web Service provides the so called Web

Service Definition Language (WSDL) to a client. Beside the Web Ser-

vice’s interfaces and other information the WSDL conta ins the URL to

access the respective Web Service. The Control Center Server uses the

Microsoft Windows Communication Foundation (WCF). Web Services

implemented with the WCF construct the above mentioned URL using

the host name and not the web site’s domain name. To construct this

URL using the web site’s domain name, a Host Header has to be confi-

gured for the respective https binding.

The Microsoft TechNet article “Configure a Host Header for a Web Site

(IIS 7)” (http://technet.microsoft.com/en-

us/library/cc753195(WS.10).aspx) discusses the steps needed to confi-

gure Host Headers within IIS 7 in detail. For the sake of simplicity the

following excerpt shows the configuration of a Host Header for an

https binding.

http://technet.microsoft.com/en-us/library/cc753195(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc753195(WS.10).aspx


To configure a site named <web_site> (e.g. Default Web Site) with an exis-

ting https binding for the IP address <ip_address>, on port 443, to have a

host header named <host_header> (e.g. www.my-domain.com), type the

following at the command prompt:

%SystemRoot%\System32\inetsrv\appcmd.exe set site /site.name:

<web_site> /bindings.[protocol='https',bindingInformation='<ip

address>:443:'].bindingInformation: <ip address>:443:<host_hea-

der>

Exemplarily, the following screenshot shows the above mentioned parame-

ters (<web_site>, <ip_address> and <host_header>) and where they can be

found in IIS 7.

The following example shows the command line for the specification of the

host header (hostname) “www.my-domain.com” for the https binding of the

Default Web Site used for all IP addresses (“*”).


Default Web Site /bindings.[protocol='https',bindingInforma-

tion='*:443:'].bindingInformation:*:443:www.my-domain.com

The following example shows the command line for the specification of the

host header (hostname) “www.my-domain.com” for the https binding of the

Default Web Site used for the IP addresses “1.2.3.4”.


Default Web Site /bindings.[protocol='https',bindingInforma-

tion='1.2.3.4:443:'].bindingInformation:1.2.3.4:443:www.my-do-

main.com


SERVER CONFIGURATOR

The Server Configurator is a tool to specify transport security (https) for

all Servicetrace web services at once. The tool may be found within the

Servicetrace installation directory.

After starting the Server Configuratior two tabs may be used to confi-

gure transport security.

Within the Service Settings tab a user is able to specify the URL scheme

or schemes, which are supported by the endpoints of the Servicetrace

web services (server-side). In other words, a user may specify, at which

ports the Servicetrace web services should listen: http (port 80 by

default) and/or https (port 443 by default). As the checkboxes suggest,

the web services may listen to both ports at the same time.

The Service Settings must correspond to the bindings specified by the respective web site within the Microsoft Internet Information Ser-vices (IIS). Thus, if http and https are both enabled, the IIS must enable two bin-dings as well: one for http and one for https


As the name implies, the Client Settings tab is used to specify the URL

scheme, which is supported by Servicetrace clients. In the Servicetrace’s

context clients denote different modules: agents, web applications, and

web services, which communicates with each other. In contrast to the

Service Settings a user is able to select only one URL scheme: http or

https. A client is not able to support more than one URL scheme at a

time.

If transport security (SSL or https) is enabled, the respective binding

within the IIS must specify a certificate. Certificates are issued to a name

(hostname, full qualified domain name, etc.). This name must be specified

in the text box “domain name” and will be used to perform the transport

security. An empty text box results in URLs using “localhost” to connect

to the respective Servicetrace web services. This would imply that the

respective certificate was issued to “localhost”.

The Server Configurator will restart the Microsoft Internet Informa-tion Services (IIS) during the endpoint configuration .


CONTROL CENTER AGENT

At the side of each Control Center Agent using transport security (https)

do the following steps:

If the certificate used for transport security (https) is signed by a trus-

ted Root Certificate Authority (Root CA) already registered within

Microsoft Windows (e.g. VeriSign, Thawte, etc.) nothing has to be

done with respect to certificates.

Due to the Chain of Trust the respective certificate is valid, because

the signing Root CA is known as trusted Root CA by the Operating

System.

If the certificate used for transport security (https) is signed by a Root

Certificate Authority (Root CA) not registered within Microsoft

Windows, do one of the following:

Deploy the certificate of the Root CA, which has signed the used certificate, to the Local Computer’s “Trusted Root Certification Authorities” key store of each Control Center Agent host. See the chapter 0 for a detailed description.

Deploy the certificate of an Intermediate CA, which has signed the used certificate, to the Local Computer’s “Trusted Root Certification Authorities” key store of each Control Center Agent host. See the chapter 0 for a detailed description.

Open the Windows Services and stop the “Servicetrace Agent” service.

Start the Agent Configurator, which can be found in the Windows Start

menu under “All Programs / Servicetrace / Agent / Agent Configurator”

Enable the flag “Use HTTPS as protocol layer”.

For the setting „CC Server to connect“ it is very important to specify the name of the Control Center server host and not its IP address , be-cause the name oft he certificate must match the name of this setting – i.e. the certificate ’s name must match the domain name oft he resulting URL. This ist o prevent Phishing attacks and is required by the Microsoft Communication Foundation (MCF).

Press OK. Answer the question about restarting the service with

“Yes” so that your changes will come into operation.


WEB APPLICATIONS

At the side of each host running the Servicetrace web applications within

a browser and using transport security (https) the following steps have

to be performed.


ted Root Certificate Authority (Root CA) already registered within

Microsoft Windows (e.g. VeriSign, Thawte, etc.) nothing has to be

done with respect to certificates.

Due to the Chain of Trust the respective certificate verifies as valid be-

cause the signing Root CA is known as trusted Root CA by the Opera-

ting System.


ted Root Certificate Authority (Root CA) not registered within Micro-

soft Windows one of the following steps has to be performed:

Deploy the certificate of the Root CA, which has signed the used certificate, to the Local Computer’s “Trusted Root Certification Authorities” key store of each Web Cli-ent host. See the chapter 0 for a detailed description.

Deploy the certificate of an Intermediate CA, which has signed the used certificate, to the Local Computer’s “Trusted Root Certification Authorities” key store of each Web Client host. See the chapter 0 for a detailed description.


APACHE TOMCAT

The Servicetrace web applications use Apache Tomcat1 as Java Servlet

Container, which is bridged to the Microsoft Internet Information Ser-

vices (IIS). To use transport security (https) within the web applications,

the following steps have to be performed at the Apache Tomcat host.

Stop the Apache Tomcat Server using the tool “Monitor Tomcat” (Tray

icon).

If the certificate used for transport security (https) is signed by a

trusted Root Certificate Authority (Root CA) already registered

in a Java key store known by the Apache Tomcat (e.g. the sys-

tem-wide Java key store “cacerts”) nothing has to be done with

respect to certificates.

Due to the Chain of Trust the respective certificate is valid, be-

cause the signing Root CA is known as trusted Root CA by the

Apache Tomcat.

If the certificate used for transport security (https) is signed by a

trusted Root Certificate Authority (Root CA) not registered

within a Java key store known by the Apache Tomcat (e.g. the

system-wide Java key store “cacerts”), please see chapter 0 for a

detailed description to import the required certificates.

Start the Apache Tomcat Server using the tool “Monitor Tomcat”

(Tray icon).

1 Please note that Apache Tomcat is not the Apache HTTP Server! As Web (HTTP) Server the Mi-crosoft Internet Information Services (IIS) are used.

[hier eingeben] · see below all snap-ins of the computer account (local machine). to import a...

Documents