digiseal server User Guide

Transcription

1 Page 1 of 57 Server software for central automated processes secrypt GmbH Bessemerstraße 82 D Berlin, Germany Tel: Fax: mail@secrypt.de Last Revision: Support hotline: (1.99 EURO per minute in the German landline network) or SECRYPT Revision history: Date Doc. Version Remark(s) Author(s) New version EmJa Checking and release MaSc Correction AnSt Checking and release TaMi Supplement custom task MaSc Supplement trust anchor, TSL MaSc Supplement product registration MaSc Supplement for eidas regulation MaSc Supplement for signature augmentation MaSc Supplement for automatic start MaSc Note: Please read this User Guide carefully before you use the software.

2 Page 2 of 57 Contents 1. Introduction About this User Guide About digiseal server Principal means of functioning Scope of functions Background information on electronic signatures Generating electronic signatures Verifying electronic signatures Legal basis Installing and registering digiseal server Installing digiseal server Installing the driver software for the smartcard reader Updating an existing installation / Online update Registering the software and using it for the first time Generating the registration file Online registration and activating your installation Verifying your registration and licence Starting the administrator interface and configuring the installation Initial configuration of the administrator access (Configuration Assistant) Starting the user interface and connecting with the service (Login) Alternative mean: Starting the software as a process (without the Windows service) Creating and starting processes General notes on the programs user interface Configuring the most important basic functions Certificate Manager / Trust Anchor Creating processes for processing data Activating signature units for signature processes Starting processes Automatic start of processes and signature units Automatic start sample Provision of signature units Automatic start of processes... 22

3 Page 3 of Configuration of automatic start events Operating and maintaining digiseal server Using digiseal server Using the file interface Using digiseal server via the application programming interface (API) Data processing results Rebooting the system Setting the language in digiseal server Maintaining the certificate manager and the trust anchor Carrying out the online update Farming operation: Parallel operation of several digiseal server installations Providing a backup solution Descriptions of the process configurations Process Definition tab Interface tab Signature tab Settings for Adobe LTV signature (PAdES-B-LT) Configuring the PDF stamp Settings for the XML signature Settings for the EDI Custom profile Timestamp tab Augmentation tab Verification tab Configuring the verification depth Advanced verification settings Encryption tab Sending tab Custom Task tab Introduction Configuring the custom task Requirements to the external application Working principle of the digiseal server for running the custom task Interface description directives and placeholders Sample configuration of return code and command line Log / Archive tab Using INI files for the detailed configuration of processes... 43

4 Page 4 of Signing faxes with a 2D barcode Requirements for the input data Processing the input data Configuring the processing with INI configuration files Structure of the *ini file with layout information Defining the input and output areas Ignoring input data Outputting the matrix code on templates (stationery function) Appendix Overview of usable signature formats Technical Specifications Return values provided by digiseal server (verification) System requirements List of supported smartcard readers Information about verifying signatures and decrypting data Data protection - Storage of personal data... 55

5 Page 5 of Introduction 1.1. About this User Guide The main task of the digiseal server software is to automatically sign, verify and timestamp data. This User Guide provides an overview of the functions and describes, how to operate the digiseal server. This User Guide will focus on the following aspects: Method of functioning: Read section 1.2 to obtain an overview of digiseal server and how it functions. Initial start-up: Section 2 provides information about the installation and registration. Configuration: To configure and start the processes, read sections 3 and 4. Operation and servicing: Section 5 explains the most important processes required for operating digiseal server. Description of the process configuration: Section 6 explains how the individual processes and process tasks are configured. Further documents provide information on the following aspects: Application programming interface (API): digiseal server has an application programming interface (API). This programming interface enables the functionalities of digiseal server to be used from other programs. Please read API documentation for further advice. Section 5.1 (page 25) describes how to access digiseal server via APIs. Security note: In order to generate and verify legally complaint signatures, digiseal server must be operated in a secure environment and must be protected against manipulation. Please read the notes in the digiseal server_sicherheits-bedienungsanweisung.pdf document that is included in the installation directory. secrypt GmbH reserves the right to make technical changes to the software supplied. Please read the General License Conditions of secrypt GmbH carefully before installing digiseal server. It is assumed that you are familiar with the Windows desktop and standard Microsoft applications (e.g. Word, Outlook). All companies and brand names referred to, including their trademarks, are the property of their respective owners and are used merely for identifying and describing the products. Please read this User Guide carefully before using the software About digiseal server Principal means of functioning digiseal server consists of the Windows service digiseal server service. This service starts automatically when starting the operating system. Figure 1 depicts how digiseal server functions. You can access and configure the service via the client interface. Within digiseal server you can create different processes. Each process can process inputted documents and carry out different process tasks on the inputted data such as Sign, Verify and Send. In order to generate a signature, the processes use signature units. These can be in the form of a signature card, software certificate or PKCS#11 token.

6 Page 6 of 57 The respective signature units are activated by the certificate holder and are assigned to one or more processes. Each process then uses the signature unit(s) assigned to it. The assignment of several signature units to a process determines the performance capability of a process. Processes without signature generation use so-called working units that are automatically started when activating the process. Figure 1: Internal structure of digiseal server and how it functions Scope of functions Each process in digiseal server processes the inputted data in accordance with the activated process tasks. Table 1 describes the possible process tasks carried out by digiseal server. Depending on the scope of your license, when installing your digiseal server only those process tasks can be activated that are covered by the license. Table 1: Overview of the possible tasks in a process Process tasks Sign Timestamp Augment Verify (SIG) (TSP) (AUG) (VER) Description Generates a signature on the inputted data in accordance with the selected signature exchange format Using a timestamp service, this generates a timestamp and stores this in a file. If the signature is also active in the process, the timestamp is embedded in the signature. Augments signatures with timestamps and validation material, to enable later verification and preservation of the probative value. Verifies a signed document and stores a verification report in the configured output directory (Positive, Negative, Resubmission). Encrypt (ENC) Encrypts the processed data.

7 Page 7 of 57 Send (SND) Sends the processed data by . Custom task (CUS) Customizes data processing by integrating external applications Background information on electronic signatures Digital signatures refer to a process in which, for any given digital data set, an additional data set (the so-called signature) is calculated. By evaluating the digital signature, it can be determined whether the signed data was modified after the signing process. The process for generating digital signatures can also be used for generating electronic signatures. These have a specific legal meaning. When generating these types of signatures, additional certificates are used that contain information on the owner of the certificate. These certificates are anchored in the signature. When verifying the signature, the producer of the signature can be determined by reading out the certificate. The certificates are secured by a trust centre. The use of the certificate by third parties is prevented by using a password or PIN. These properties make it possible in Germany, for example, to use an electronic signature in a manner equivalent to a handwritten signature (according to 126a of the German Civil Code (BGB)) in the form of the so-called qualified electronic signature (QES). In order for the electronic signature to be legally effective, the legal requirements must be observed for the country of use and the respective application scenario Generating electronic signatures Signatures are essentially generated in three stages: Calculation of the hash value (digital fingerprint) for the data Attachment of the hash value to the certificate Encryption of this data with the signature card or the cryptographic key from the software certificate after entering a PIN or a password The result is an electronic signature, which depending on the exchange format is either stored as an own file (e.g. *.p7s) or is directly embedded in the signed file (e.g. *.pdf) Verifying electronic signatures Signatures are verified in the reverse sequence: Decryption of the signature in order to obtain the original hash value New calculation of the hash value based on the data Comparison of the newly calculated hash value with the encrypted hash value The signed data is unchanged if the decrypted and newly calculated hash value are identical. In order to identify the producer of the signature, the embedded certificate is evaluated. This is signed with the root certificates from the trust centre, which means that the information in the certificate is trustworthy. In addition, an online query can be made with the trust centre to determine the status (valid, blocked or unknown) of the certificate in question. This verification comprises the following additional steps: Extraction of the certificate from the signature Verification of the certificate signature and establishment of a certificate chain as far as a trustworthy certificate (root certificate, issuer certificate)

8 Page 8 of 57 Verification of the certificate status by means of an online query with the trust centre. The combination of certificates, trust centres and electronic signatures is described as the Public Key Infrastructure (PKI) Legal basis In order for electronic signatures to be legally effective, the legal requirements must be observed for the country of use and the respective application scenario. Since 1 July 2016, the "regulation on electronic identification and trust services for electronic transactions in the internal market" (eidas) applies in all EU Member States, which means that former national signature laws are now obsolete. In Germany the eidas directive substitutes the former German Digital Signature Act (SigG) and the associated Digital Signature Ordinance (SigV). SigG and SigV previously declared the requirements that had to be complied with by users and products when generating and verifying electronic signatures. Please follow the instructions provided in the Operating instructions for the secure use of digiseal server. This document is provided as a pdf file (digiseal_server_sicherheits-bedienungsanweisung.pdf) in the installation directory for digiseal server.

9 Page 9 of Installing and registering digiseal server 2.1. Installing digiseal server secrypt supplies the software by sending a download link per . This also contains your license information (license number, transaction number). Please read the notes in the carefully. These explain how you can ensure the integrity of the download by verifying the enclosed signature file. Install the installation program and start the installation with a double click. Follow the instructions provided by the installation software and confirm your entries by clicking the Continue >> button. Please enter your license information completely and correctly Installing the driver software for the smartcard reader The necessary driver software needs to be installed in order to communicate with smartcard readers. The driver software is either available in the card_reader_software sub-directory in the digiseal server installation directory or on the website of your smartcard reader manufacturer. Install the driver software for your smartcard reader and follow the instructions provided by the installation program Updating an existing installation / Online update If digiseal server (or higher) is already installed, this will be automatically recognised by the installation program. The update adopts your existing process configurations and settings. Alternatively you can update the software by using the online update system. For this purpose open the 3.6 Software Update tab. Click the Check for updates now button to check whether there are any updates. Follow the software instructions to start the update process. A backup of the installed version is created when beginning the update. This backup version can be reactivated with the help of our support team Registering the software and using it for the first time You need to register the digiseal server software component before it can be used, whereby your license information is linked with the specific installation on the target system. For this purpose, a previously generated registration file is transmitted to secrypt, which is used for completing the registration. Please send the digiseal server.register registration file per to the address of the registration service: registration@secrypt.de. The necessary license information (license number, transaction number) is provided in the delivery Generating the registration file You can find the digiseal server.register registration file in the installation directory for digiseal server. If the file does not exist there, please start the Client Interface (see Section 3.2, page 12). The Configuration Assistant appears. Click the Register button to generate the required file Online registration and activating your installation The following section describes how to register and activate your installation:

10 Page 10 of 57 License information Your license information (company, license number, transaction number) is provided in the delivery . After the software installation, please send the digiseal server.register registration file per to the address of the registration service: The registration is then transferred to us and processed. After successfully registering, we will send a Zip folder with two files to your given address. Copy the digiseal server.registered and digiseal server.registered.signature from the Zip archive into the installation directory. The digiseal server service then needs to be restarted via the Windows Services console. digiseal server is then installed. Start the user interface by double-clicking on the Desktop symbol and carry out a basic configuration as described in Section Verifying your registration and licence Your installation of digiseal server is defined for a specific scope of functions in accordance with the licence you have acquired. The maximum number of possible signatures and verifications is accordingly limited to the amount you have purchased. The 4.2 Registered Configuration tab shows the registered and already used transactions. The tabs 1.4. Statistics and the 3.4. Usage Protocol provide a detailed overview of the transaction usage. If you would like to extend your licence, please get in touch with our sales department (sales@secrypt.de). Please use the event notification (see Section 4.2, page 15) in order to be informed in time about transactions that are due to expire.

11 Page 11 of Starting the administrator interface and configuring the installation 3.1. Initial configuration of the administrator access (Configuration Assistant) The digiseal server software must be configured before using it for the first time. Figure 2 shows the Configuration Assistant that helps you to carry out the configuration. The Configuration Assistant starts automatically if the configurations for operating digiseal server have not yet been carried out. You can also start the Configuration Assistant manually in the Local Settings tab (via the Login tab, Figure 3). Figure 2: Configuration Assistant for registering the software, creating the access certificate for the administrator and for starting the Windows service. For security reasons, the Configuration Assistant is only available when it is started on the hardware where the digiseal server is installed. The Configuration Assistant provides an overview of the state of your installation. A green check box shows that a configuration step has already been successfully carried out. A red triangle with an exclamation mark in it indicates that a configuration step has not yet been completed. The Configuration Assistant is used to carry out the following four steps: Registering the software: Clicking the Register button generates a registration file that is necessary for the registration process (see Section 2.2, page 9). Server certificate: digiseal server (Windows Service) communicates with the user interface via secured communication channels. This requires an individual certificate on the server side. In order to generate it, please click on the Generate certificate button and follow the instructions. You can later identify digiseal server using this certificate. You will then no longer require the password for the certificate. User accounts: Administrator access is required in order to operate digiseal server. In order to create a new administrator, click the Create administrator button. Follow the instructions on the screen to

12 Page 12 of 57 generate an administrator certificate. You will use this certificate later (*.pfx file and password) to login on digiseal server as the administrator. digiseal server service: In order to start digiseal server as the Windows system service, click on the Start service button. If required, the Windows Services console will provide you with further information on the state of the service. Once all the settings have been correctly made, click the OK button to start the user interface Starting the user interface and connecting with the service (Login) On the desktop there is a digiseal server shortcut. Double-click on the shortcut to start the application. If digiseal server is not configured, the Configuration Assistant appears. Please follow the instructions and then click OK to start the client application (see sections 2.2 and 3.1). If the software is correctly installed, the digiseal server user interface appears. You need to connect yourself with the service by first of all logging in. For this purpose select the user certificate that was configured as the user account in digiseal server (see Section 3.1). Enter your password and click the Login button. Figure 3: digiseal server Login tab for connecting with the Windows service. Under Connection details, please specify the IP address and port to be used for connecting with your installation of digiseal server. Your administrator will provide you with these details. In the standard works setting, the port is set to If no server certificate is indicated, the certificate for the selected server installation must be confirmed once more during the login. Please note that a connection to a remote digiseal server presupposes that this has been accordingly activated in your licence.

13 Page 13 of 57 In the Local Settings tab you can configure, for example, the language or a proxy server and provided that you have started the interface on the installation computer you can start the Configuration Assistant. Some changes to the settings will only come into effect after restarting the software Alternative mean: Starting the software as a process (without the Windows service) For compatibility reasons, in some cases digiseal server needs to be installed not as a Windows service but as a process with user rights. For this purpose the dsserverservice.exe program is started with the user parameter. In this case, ensure that the Windows digiseal server service is stopped and deactivated. For this purpose you will need to use the Windows Services console in your operating system. After digiseal server starts as a process, a new system tray symbol appears alongside the system clock. Rightclick on this symbol and click configure to start the user interface. You then make the connection as described. If digiseal server is not operated as a Windows service, logged-in Windows users must not be logged out.

14 Page 14 of Creating and starting processes This section describes, by way of example, how processes are created in digiseal server. This assumes that the software has been installed and configured in accordance with the descriptions in Sections 2 and 3. When configuring digiseal server please take in account that it is normally installed as a Windows service. Services have Local system rights and therefore cannot necessarily access network drives General notes on the programs user interface After starting the program interface and successfully logging in, the main window and console window for digiseal server are displayed (Figure 4 and Figure 5). Figure 4: The main user interface for digiseal server with the main menu, tab menu and an active tab. The individual tabs are numbered, e.g Signature / Working Units. On the left-hand side of the main window is the main menu with the following areas: 1. Operation: Here operations and Signature Units can be started. 2. Process configuration: This area is used for creating and configuring processes. 3. Administration: This area is used for entering important settings (status reports, user accounts, API) for digiseal server. This is also where the Online Update is located. 4. Info / Help: This area provides you with information on, for example, your licence. 5. Logout: This is where you log out of digiseal server. Corresponding views appear in the main window in accordance with the category chosen. The tabs divide the main menu items into further areas. In this User Guide the individual tabs are referenced by means of a numbering system that refers to the main menu item and the respective tab. For example, 1.2. stands for the Signature /Working Units tab under the 1. Operation main menu item.

15 Page 15 of 57 In addition to the main window with the tabs there is also a console window (Figure 5). digiseal server uses the console window to issue reports on the process status. These reports only appear in the console when the user interface is connected with the service (Login). Figure 5: Console window for digiseal server for displaying information about the process status and the data processing Configuring the most important basic functions Once digiseal server has been successfully installed, you need to configure the basic functions. For this purpose you need to check the information on the following tabs: 3.2. Basic Configuration Certificate Manager / Trust Anchor: The configuration of the trust anchor is an important part of the basic configuration and described in the chapter below Basic Configuration log file: Here you configure a log file in which outputs can be stored. This data provides an important tool for retrospectively analysing the operation or when requiring support. The log file should be outputted locally on the installation system Event Notification: In this tab you can configure an SMTP server and a recipient address. Warnings and status s are sent to this address. We recommend that you set up a dedicated account in order to receive event notifications. This mail account will then be read by the responsible administrators or forwarded to them Certificate Manager / Trust Anchor Certificate manager Use the certificate manager to configure the trust anchor for signature and certificate verification. Set the certificate source and the certificate trust status. The TSL certificate store, the secrypt certificate store and the user certificate store are sources of certificates for the trust anchor. Each source can be activated or deactivated. The user configures the trust status of a certificate by clicking the right mouse button or the "Change trust status" button. The certificate trust status can be set to one of the following values: "trusted", "untrusted", "unknown trust status" or "ignore certificate".

16 Page 16 of 57 Trusted Services / TSL (Trust-service Status List) Per default the EU Trusted Lists of Certification Service Providers published by the European commission is used to supply and update the trustworthy issuer and root certificates of the European trusted services. It is recommended to activate the automated weekly check for an update. Folder for the trust anchor Folder for the TSLs (Trust-services Status List): %PROGRAMDATA%\digiSeal server\certificates\tsl\ Folder for the secrypt certificate store: %PROGRAMDATA%\digiSeal server\certificates\secrypt\ Folder for the user certificate store: %PROGRAMDATA%\digiSeal server\certificates\user\ 4.3. Creating processes for processing data The 2. Process Configuration main menu item enables you to create and configure processes in digiseal server. These processes are used for processing inputted data by applying the activated process tasks (e.g. Sign or Verify) to the data. The available process tasks and the maximum number of processes depend on the licence acquired. a) b) Figure 6: Process configuration without processes (a) and the dialog box for adding a new process (b). Fig 6 (a) shows the view for the 2. Process Configuration main menu item. If no processes have been added, the process list is empty. In order to add a new process, click the Add button. A dialog box appears (b), in which you enter the name for a new process. In addition you need to select the signature exchange format, even if the later process does not cover the generation of signatures. Finally you need to define a directory to be used by the process for exchanging the data. If the Append process name to the chosen directory option is enabled, a sub-folder with the process name will be automatically created in the selected process directory. For signing processes: Depending on the selected format, only data types permitted for the respective format will be accepted via the file interface. Table 7 in the Appendix (page 49) provides an overview of the formats and the permissible input data.

17 Page 17 of 57 Figure 7: The desired process tasks are activated in the 2.1. Process definition tab. Once a process has been created, the 2.1 Process definition view appears (Figure 7). Here you activate the process tasks that the process is intended to carry out on the inputted data. Use tabs 2.2 to 2.10 to configure the process tasks in detail. Only the tabs that describe activated process tasks are visible. You can find a detailed description of the individual tabs in Section 6 Descriptions of the process configurations Activating signature units for signature processes In order to start a process with an activated signature function, a signature unit must first be started and assigned to this process. Figure 8 shows the 1.2. Signature / Working Units tab. The available interfaces to the signature units are listed and identified with a corresponding symbol. The interfaces are: Smartcard reader Software certificate PKCS#11 token Click the Search signature units button to update the list.

18 Page 18 of 57 Figure 8: List of available signature and working units with the smartcard reader, software certificate and PKCS#11 interfaces In order to start a signature unit, click the start button to the right of the desired signature unit. Depending on the type of signature unit, dialog boxes now appear that enable you to activate the signature unit: 1. [software certificate only] Choice of software certificate (PFX file) 2. [PKCS11 only] Choice of PKCS#11 interface 3. Configuration of the signature task (see following description) 4. Confirmation of the signature task 5. [signature card only] PIN entry digiseal server supports not just standard communication with signature cards inserted in smartcard readers but also the use of PKCS#11 tokens. If it is intended to communicate with a signature creation device (e.g. HSM, USB token, smartcard) via an external PKCS#11 interface, the respective PKCS#11 library can be entered after clicking the start button in the PKCS#11 token line. The main step in activating a signature unit is to configure the signature task in the dialog box depicted in Figure 9. Here you should specify the following parameters: 1. Choose the processes can use the signature unit for signing. 2. Limitations to the signature unit (number of permitted signatures or time window). 3. Certificate to be used for the signature. 4. [optional] PIN entry via the card reader keyboard

19 Page 19 of 57 a) b) Figure 9: a) When configuring the signature task, the signature unit being started is assigned to one or more processes. b) Dialog box for confirming the signature task. In the upper part, mark the processes that can use the signature unit for generating signatures. Several processes can be selected for a working unit. You can also activate several working units for a process. This assignment determines the performance capability of a process. Furthermore, in accordance with statutory requirements the signature capability of the working unit is limited in the dialog box in terms of the number or duration. For this purpose, please enter the maximum number of permitted signatures and/or specify a time window after which the card disables the signature readiness. If the PIN is not to be entered via a smartcard reader, disable the Enter PIN via card reader keyboard option. In this case enter the PIN in the text field on the left-hand side. Clicking the Activate button opens the confirmation window (Figure 9b). This window once again displays all the information on the selected signature process to be carried out. Clicking the Confirm button starts the signature unit, which after entering the PIN is active under the selected conditions. The signature unit is now ready to generate signatures and can be used by the assigned processes. The unit is active so long as the defined limitations do not apply and the card is valid Starting processes The actual signature process can now be started via the 1.1. Processes tab. To do this click the start button for the desired process. Please remember that you can only start the processes for which a signature unit is activated or for which no signature unit is required (e.g. verification).

20 Page 20 of 57 Figure 10: Tab 1.1. shows the configured processes and their status and enables the processes to be started or stopped. Using symbols the process list indicates the process status and which process tasks are activated for the process. Table 2 provides an overview of the symbols used. Table 2: Explanation of the symbols in the 1.1. Processes tab. Process status Process task (type) Action symbol Process inactive Process ready Process active Sign (signature unit active) Sign (signature unit inactive) Timestamp Augment Verify Encrypt Send Custom task Process cannot be started Start process Stop process Show information on this process As soon as a process is activated, it can be inputted with data for processing. The data is inputted into the process via the agreed directories (file interface) or via the API. You can find further information on this in Section 5 Operating and maintaining digiseal server.

21 Page 21 of Automatic start of processes and signature units Automatic start enables the digiseal server to start processes and signature units automatically. Figure 11: Tab 1.3. Automatic Start is used to automatically start processes and signature units Automatic start sample Perform the following steps to enable the automatic start: 1. Open tab 1.3. Automatic Start. 2. Press Signature unit + / - 3. Choose the signature certificate that shall start automatically. Signature certificate from different card readers may be displayed at this stage. 4. Activate the chosen signature unit as usual. 5. Chooses Adopt -> Adopt and apply to trigger the automatic start. The signature unit is now activated and all related processes are running.

22 Page 22 of Provision of signature units A signature unit can be provided either by pressing Signature unit + / -, or by using the activation dialog under 1.2. Signature / Working Units. Thereafter the digiseal server has all information needed for an automatic start. Provision of signature units for the automatic start: Signature cards can be provided by pressing Signature unit + / -. Software token certificates, PKCS#11 libraries and also signature cards can be provided by choosing the activate for autostart option in the activation dialog under 1.2. Signature / Working Units. Use the configuration symbol (weel) or the right mouse button to remove a provided signature unit. Under the following circumstances a signature unit has to be provided again: Change of the properties of the signature task since last provision. Amount limit or time limit claimed in the signature task dialog of last provision is reached. Signature relevant change of the process properties since the last provision Automatic start of processes Under Automatic start of processes all processes and signature units are listed, that are can be used by the automatic start. Checked processes and signature units will be started at the next automatic start event. Unchecked processes and signature units will be stopped at the next automatic start event (if they have not been started manually).

23 Page 23 of 57 A checked box does not mean that the corresponding process or signature unit is running in this moment, but that it will be considered for start at the next automatic start event. Processes and signature units with a gray checked box cannot be started anymore. The signature unit has to be provided again by the owner Configuration of automatic start events Im Folgenden wird erklärt, wie Ihre Änderungen im Reiter 1.3. Automatic Start angewendet werden: Adopt : Provision of a signature unit The provision of a signature unit is always adopted right away. The signature unit is then activated for the corresponding processes. Configuration of processes and signature units All changes of the configuration of processes and signature units are only adopted when you press Adopt. Removal of signature units The removal of a signature unit is only adopted when you press Adopt. Changes that are confirmed with Adopt, but not with Adopt and apply will be considered at the next automatic start event. Adopt and apply : Starting and stopping of processes and signature units Choose Adopt and apply, if the digiseal server shall start and stop the configured processes and signature units right away. Discard : Choose Discard if you want to ignore your latest changes. Automatic start event Under Options -> Automatic start the trigger for the automatic start event can be configured. The default settings offers a balanced configuration between automatic start event behavior and performance. Please contact the secrypt support before changing these default settings. The automatic start is triggered at the following events: At the start of the digigseal server service On smard card insertion and removal (card change events are periodically checked, at intervals between 20 sec and 2 min). Periodically in the configured interval (default configuration is every 60 min).

24 Page 24 of 57 On Adopt and apply by the user. Amount of started software token certificates and working units The amount of started software token certificates and working units can be configured by using the cconfiguration symbol (weel) or the right mouse button in the corresponding table row. Usage notes and known issues To keep track of starting and stopping the same process or signature unit, always use either automatic start only or manual configuration only. Some card readers (e.g. from Reiner SCT) force the re-insertion of the signature card after a restart of the system. Cards in such card readers are therefore not directly available after a restart of the system, but must be removed and inserted manually.

25 Page 25 of Operating and maintaining digiseal server 5.1. Using digiseal server In order to process files using the started processes, the file interface or the application programming interface (API) are used. Both are explained below Using the file interface During the configuration of the processes, input and output directories are defined in which the processes work. The processes monitor their input directory and process the files that are stored in it. The processes data is store in the output directory. The type of input and output data depends on the active process tasks and their configuration. Please note the following aspects in this regard: The file interface checks the extensions for the input data. Files with invalid extensions are not processed. For example, a PDF file must always end with.pdf. If files with the same name are already in the output directory, the input files are not processed. When verifying detached signatures it should be noted that both the signed data as well as the signature file have to be transferred to the input directory. The signature file must be given an identical name to the data file with the additional extension: e.g. rechnung.txt and rechnung.txt.p7s. During the verification, the verification reports are stored in the specified directories (see Section 6.6, page 34) Using digiseal server via the application programming interface (API) digiseal server has an application programming interface (API). This is used by other programs to pass data through processes of the digiseal server. In order to enable other software to use this API, this needs to be activated (3.5. Proxy/API tab). In addition, the API access must be enabled for each process. To do this, activate the API access for the respective process on the 2.2 Interface tab. To secure the API access, a software certificate is specified here with which the communicating software component must authenticate itself. In order to generate your own software certificate, use the dsgeneratepfx.exe command line tool in the digiseal server installation directory Data processing results Some of the possible results produced by the data processed in the various processes are listed below: File in the output directory (sign) Verification report in the output directory (verification) Extracted signature object in the extraction directory (verification) Timestamp in the output directory Return values via the API Sent with file in the attachment Each process run is logged in the console window (Figure 12) and in the log files.

26 Page 26 of 57 Figure 12: Console window with information on the process job and the processing results. The log for a process job contains the following information: Key word (process job or process result) Starting time of the process job Process definition (SIG TSP AUG VER ENC SND CUS) Process name Job counter Activated signature / working unit Interface and source Name of the input file The information on the process result also includes the: Hash value for the input data Output file Second output file (optional) Number of successfully completed jobs Limitation (number of permitted signatures or the time at which the smartcard is deactivated) End time Verification result (in accordance with Table 9 in the Appendix, page 53) Error text [optional] Process status (successful / incorrect) 5.2. Rebooting the system After rebooting the system, it should be noted that the processes are deactivated. Please therefore note the following points when restarting digiseal server: The Windows digiseal server service must be started.

27 Page 27 of 57 All processes are deactivated. In order to start the processes, first of all activate the signature units for the signature processes and then start the processes Setting the language in digiseal server You have the following possibilities to set the desired language. Language used by the user interface: Before you connect to the user interface, open the Local Settings tab and select the language there. After restarting the software, the user interface will be shown in the changed language. Please note that this does not change the system language of digiseal server. The logs and outputs will continue to be outputted in the defined system language (3.2. Basic Configuration tab). Language used by the system (logs, outputs): In order to change the system language, open the 3.2. Basic Configuration tab and change the language setting. Language used by the verification report: In the 2.6. Verification tab you can set the language to be used for the verification report for the selected process Maintaining the certificate manager and the trust anchor In order to verify signed documents, the issuer and the root certificates used by the trust centres must be part of the trust anchor. These issuer certificates are used for verifying the authenticity of the certificates used by the signature producer. The information that a signature originates from the specified person is only trustworthy if it is signed with one of the provided issuer certificates (see Section 1.3.2). The administrator is responsible for maintaining the trustworthy certificates of the trust anchor using the certificate manager and, if required, installing new certificates. To update the trust anchor with the certificate manager use the following tabs: Tab 3.2. Basic Configuration Certificate Manager / Trust Anchor: The standard certificate manager and standard trust anchor are configured here (see chapter 4.2.1). Tab 2.6. Verification Advanced settings: If necessary, a different certificate store can be configured for the selected process. The process will then exclusively use the certificate from this directory. Store the new certificate as a *.cer file in the DER Coded Binary X.509 format. Then restart the respective process. Use the certificate administration system in your operating system to convert certificates into the required format. Only store trustworthy certificates from trust centres in the issuer directory Carrying out the online update Use the 3.6. Software Update tab to check whether a more up-to-date version is available. Follow the instructions if you wish to install a new version. The availability of a new version will also be published in an event notification sent by (see Section 4.2) Farming operation: Parallel operation of several digiseal server installations In order to improve the performance capability, several digiseal server installations can work together. digiseal server provides a farming functionality within the system for this purpose. Provided that several installations work with the same input directory and a corresponding filelock.100 configuration folder has been stored there, the processing of the inputted data is divided between the participating installations. Carry out the following steps to configure digiseal server for farming operation:

28 Page 28 of Install the software on two or more systems. 2. Configure identical processes on both installations. The processes use the same input and output directories. 3. Create different directories for the log files. 4. Create a folder filelock.100 in the configured input directory. The individual digiseal server installations exchange information via the filelock.100 folder. The farming operation enables different installations to work together with the aim of achieving maximum performance. It is not aimed at spreading the use of the allotted number of signatures and verifications among the installations. If the filelock folder does not exist, the various installations will access the files in the input directory in an uncoordinated manner. This will inevitably cause problems with the data processing. If digiseal server is used via the API, the software that uses the API is responsible for distributing the jobs on the different systems Providing a backup solution Should the main system fail, the aim of the backup concept is to secure the functions of digiseal server by providing a second installation. The backup system is either automatically triggered or is activated by the administrator if the main system fails. The same steps are always taken to provide a backup system: 1. Installation of the second system analogous to the main system 2. Registration of the installation 3. Configuration of the second system analogous to the main system 4. Activation of the signature cards and starting the processes 5. Adjustment of the operational environment so that the data being processed is directed via the backup system (redirection of the data flow) Several steps are carried out to prepare for a failure as part of the backup concept. With a Cold Backup system, steps 1 and 2 are carried out before the failure. After the failure, the backup system is activated with the remaining steps 3-5. Make sure that a current description of the required processes is available so that the backup system can be correctly configured. A Hot Backup system covers steps 1-4 so that the back-up system is ready for implementation. Should the main system fail, only the data flows need to be redirected. This can be done automatically, whereby this switchover has to be realised by the administrator or the participating software. Always ensure that the backup system is also adjusted should the main system be reconfigured. Document the document workflows and the configuration of digiseal server. This will enable the backup system to be started as soon as possible.

29 Page 29 of Descriptions of the process configurations This section describes the individual tabs under the 2. Process Configuration main menu item. These show how the process tasks are configured. The settings in the individual tabs always refer to the selected process. The process configuration can only be changed if the process is stopped and no signature units are activated for the process Process Definition tab This tab determines which process tasks are to be carried out by a process. To activate a process task, enable the respective check box. Figure 13 shows the configuration of an example PDF LTV signature (PAdES-B-LT) process for signing PDF documents and augmenting the signatures. Figure 13: Example depiction of the process configuration with the process tasks Sign and Augment activated. The activated process tasks are processed sequentially. In principle, for every process the process tasks Sign, Timestamp, Augment, Verify, Encrypt, Send and Custom Task can be activated in suitable combinations. Please note that, depending on your license, not all process tasks may be available. A short description of the process tasks is provided in Table 1 on page 6. The detailed configuration of the process tasks is carried out in the tabs under the 2. Process Configuration main menu item and is described in the following section Interface tab In the 2.2. Interface tab (Figure 14), you configure the interface for the respective process through which the data can be incorporated in the process. The following interfaces are available:

30 Page 30 of 57 File interface (see 5.1.1): Inputted files are received by digiseal server in the input directory. After their processing, their results are stored in the output directory. Activate the interface and configure the directories. API programming interface (see Section 5.1.2): The process is available via the API. Configure a certificate with which API users must authenticate themselves in order to be able to use the process. Ensure that the access rights to the directories for the file interface are set so that no unauthorised persons are able to affix a signature to a file. Figure 14: Tab with the activated file interface and API for the selected PDF LTV Signature process. To access digiseal server via the API, the software communicating with digiseal server must authenticate itself with the specified certificate Signature tab This tab is used for configuring the signature if this process task is activated for the process. Figure 15 shows the tab. Here you can configure the following settings: Choice of desired signature format for the files. Please note that most signature exchange formats place specific demands on the input data. For example, only PDF documents can be affixed with a PDF signature (see Section 8.1 Overview of usable signature formats, page 49). Choice of additional information to be embedded in the signature: the OCSP response, revocation list and the signing time. It is only necessary to activate one of these options in special cases. Choice of hash functions for advanced users. The software automatically chooses the currently applicable algorithm. Optional configuration of PDF signatures (see Section 6.3.2, page 32), FAX signatures (See Section 7, page 44), XML signatures and the EDI Custom profile.

31 Page 31 of 57 Figure 15: 2.3. Signature tab for configuring the signature settings Settings for Adobe LTV signature (PAdES-B-LT) LTV stands for Long Term Validation. Long-term signature validation allows you to check the validity of a signature long after the document was signed. To achieve long-term validation, all the required elements for signature validation must be embedded in the signed PDF. These elements are embedded during signature creation and afterwards the document is timestamped. A PDF document with an Adobe LTV signature has the following properties: Signature certificate and all certificates of the corresponding certificate path are embedded. Certificate status information for all certificates is embedded. Signature has an additional timestamp. Timestamp certificate and all certificates of the corresponding certificate path are embedded.

32 Page 32 of 57 The following process configuration is needed to create Adobe LTV signatures (PAdES-B-LT) with the digiseal server: In the tab 2.1. Process Definition activate 2.3. Sign and 2.5. Augment. In the tab 2.3. Signature choose the signature format PAdES embedded / *.pdf / ETSI.CAdES.detached signed-data / (former PDF Reference Version 1.6) as signature format and Signature with timestamp and validation material - AdES-B-LT as AdES compliance level. In the tab 2.5. Augmentation set the same Signature with timestamp and validation material - AdES- B-LT as AdES compliance level Configuring the PDF stamp Clicking the Configure button in the PDF signature section in the 2.3. Signature tab opens the dialog box depicted in Figure 16. Here you can configure how the signature information (PDF stamp) is displayed in the PDF document being produced. Additional information such as the reason and the location of the signing can also be entered here. Figure 16: Dialog box for configuring the PDF signature (PDF stamp) In order to add your own PDF stamp, you need to create a pdfstamps directory in the installation folder for digiseal server. In the configuration dialog (Figure 16) you can then select files stored in the directory in the Bitmap (*.bmp) or PNG (*.png) formats by setting the corresponding file name in the Type box. When selecting the PDF stamp, take note of the storage requirements so that the signed PDF documents do not take up an unnecessarily large amount of storage space.

33 Page 33 of Settings for the XML signature For XML signatures, you can also select a transformation algorithm. Before affixing the signature, canonisation is used to balance out syntactic differences that can be caused, for example, by processing an XML document on different platforms. The document data remains unchanged. The canonisation also excludes comments from the signature generation Settings for the EDI Custom profile In addition to standard EDI signature formats, digiseal server also offers an additional EDI signature format called EDI Custom. By selecting a sub-profile, additional versions of the EDI signature can be selected that are not standard but nevertheless sensible and permissible for special scenarios. Table 7 in the Appendix shows which EDI signature specifications are supported Timestamp tab An external timestamp service can be incorporated via the Timestamp tab. Timestamps offer a functional supplement to electronic signatures. The use of an accredited timestamp service enables the existence of files to be verified at a specific point in time. This helps to verify the integrity of the data. Your timestamp service provider provides the required access data. The result of the process task depends on the rest of the process definition. The following results are generated: If the process does not include any signature generation, the timestamp is obtained via the hash value for the data and is stored in the form of a *.tsr file. Some data formats support the embedding of timestamps. This option can be activated in the tab. If a signature is previously generated as part of the process, the timestamp is embedded directly in the signature. If this is the case, then no *.tsr file is generated Augmentation tab The augmentation of signatures with timestamps and validation material to enhance the AdES compliance level is very important for signed data that is supposed to be stored in archiving systems and for which later verification has to be enabled and the preservation of the probative value has to be achieved. Validation material (certificates, certificate status information - OCSP, certificate revocation information - CRL) and a trusted and independent proof of existence (timestamp) are needed for the verification of signatures. Signature augmentation is the process of gathering the information and embedding them into the signature format. Signatures enhanced by augmentation can therefore also be verified in future, when the trustcenters do not provide the necessary validation material any more. Signature augmentation with timestamp provides signer independent proof of existence of the signature at timestamp time. Signature augmentation with validation material enables future verification of the signature. Choose the AdES compliance level that you want to achieve with the augmentation: Signature with validation material AdES-B-B Signature with timestamp AdES-B-T Signature with timestamp and validation material AdES-B-LT

34 Page 34 of 57 To achieve the AdES compliance level AdES-B-T or AdES-B-LT you have to configure a timestamp service under Timestamp. Please contact sales@secrypt.de if you need such a service. We recommend to use the standard settings under Validation material and Special treatment Verification tab The following verification settings can be made in the Verification tab: Activation of verification reports (XML and PDF) and language settings for the verification reports. If the Generate detailed verification documentation (XML) option is enabled, this saves not just the XML report but also online status notifications and the associated certificates. We recommend enabling the Generate detailed verification documentation (XML) option in order to archive all data relevant for a verification. Verification documentation directories: The result of the verification is the verification report with all relevant data (certificates, online status notifications). The verification reports are saved in the directories specified here in accordance with the verification result (Positive, Negative, No result / Resubmission). A list of verification results can be found in Table 9 in the Appendix. You can also set whether the verification result should be saved as a directory, ZIP file or PDF container. Extracted data (optional): With specific signature exchange formats (e.g. *.pk7) the originally signed data and the signature are combined in a single file. In order to further process the signed data, the extracted data can be saved during the verification process in the directory specified under Extracted files (optional). Depth of verification and advanced settings: In this section you can configure the verification depth. A description of this is provided in the next section (6.6.1).

35 Page 35 of 57 Figure 17: 2.6. tab for configuring the verification settings Configuring the verification depth In the Depth of Verification section, you can set the level of detail with which the signature is verified. The meaning of the various verification depths is shown in Table 3. To carry out Verification depth 2, the issuer certificates must be in the corresponding directories. Verification depth 3 requires Internet access and an address for the OCSP online verification. The addresses for the online verification are contained in the certificates and do not generally have to be entered manually. Table 3: Various verification depths Verification depth Verification depth 1 Verification depth 2 Verification depth 3 Verification step Verification of the file signature (obligatory) Mathematical verification of the signature via the file Verification of the signature certificate (optional) Verification of the signature certificate and the respective certificate chain with a local Trust Anchor 1 Verification of the signature certificate status at the time of signing (optional) Verification of the certificate validity at the time of signing based on valid OCSP responses 2 In Germany, qualified electronic signatures require the activation of Verification depth 3. The deactivation should only be carried out by an experienced user. 1 Issuer and root certificates deemed trustworthy by the user. 2 The response identifies whether the certificate is known and is valid. the revocation took place. Both the signature and the respective certificate path for the OCSP response are also verified.

36 Page 36 of Advanced verification settings Figure 18: Dialog box for advanced verification settings. Use the advanced settings dialog box (Figure 18) to configure the following settings: Certificate Manager / Trust Anchor: If necessary, a different certificate store can be configured for the selected process. It is recommended to use the global certificate store. Verification output Verification criteria: If a signed file fails to meet at least one activated verification criterion, this file is moved into the directory for resubmission. Certificate status verification: Configure for which certificates of the certificate path the certificate status verification has to be done. Important note: The following aspects need to be observed during the verification: Complete verification also includes verification of the root certificates used and their status (Verification depth 3) The system time for the operating system used must be correctly set The system must be protected against unauthorised access and manipulation Encryption tab If the processed files are to be encrypted, the Encrypt process task can be activated and configured in the 2.7. Encryption tab. The following encryption possibilities are supported by digiseal server:

37 Page 37 of 57 For symmetrical encryption a password must be entered, which the recipient also needs to be given via another secure communication channel in order to decrypt the data. Asymmetric encryption is certificate-based, whereby the certificate of the recipient must be specified. The data is then encrypted with the public key for the specified certificate and can only be decrypted with the private key belonging to the recipient. As a third possibility, the encryption parameters can be transferred to digiseal server via an INI configuration file (see Section 6.11). The encrypted data is then stored in a *.pk7 file (PKCS#7) Sending tab This tab enables you to configure how the processed data is sent by . This requires the following parameters: Access data to the SMTP mail server Information about the sender, recipients, subject heading and message text as a *.txt file. signature Activation of the configuration using INI files: Activate the Use INI-file for extended configuration option to adjust the configuration with every process run. In this case the process expects an INI file as an additional input file in which the necessary parameters are configured (see Section 6.11) Custom Task tab The Custom Task allows customized data processing Introduction For customized data processing, the digiseal server supports adding a Custom Task as an additional task to a process. The user chooses an external application that supports processing the data in the desired way. This external application is then integrated by the digiseal server into the process through a customizable command line invocation.

38 Page 38 of Configuring the custom task The following settings are needed to configure the custom task: Task name: Name of the custom task. Application (APP): Full path to the application that runs within the custom task. Sample: C:\Program Files\dsPDFlibrary\dspdftool.exe Task order: Setting the task order within the process. - Run custom task BEFORE signing / timestamping / encrypting - Run custom task AFTER signing / timestamping / encrypting Error report: In case of error, the information from STDOUT and/or STDERR can be included in the error report. Configuration of return code and command line Use directives and placeholders to configure the expected return code and the command line for the application. These directives and placeholders are explained in the following chapters. Figure 19: Tab 2.9. for configuring the custom task.

39 Page 39 of Requirements to the external application The digiseal server supports integrating an external application for customized and automated data processing when this application fulfils the following requirements: Command line The application supports being called by the command line. Input file(s) The application accepts the data to be processed as files. Output file(s) The application returns the processing result as files. Return code After successful processing the application returns with a defined return code (Error Level) Working principle of the digiseal server for running the custom task The digiseal server uses the same interfaces (file interface and API interface) to exchange the data that is processed within the custom task. All tasks defined within the process are executed in the usual order. When the custom task is next, it receives the data processed by the previous tasks. The custom task calls the external application and uses the received data as the input for the external application. If the external application successfully returns the processed data, the custom task hands this over to the next task in line. When all tasks within the process are finished, the data is returned over the file- or API interface. To achieve this working principle the digiseal server calls the external application with the command line using at least the input file and the destination for the output file as parameters Interface description directives and placeholders To run the custom task the digiseal server starts the chosen external application using all the needed arguments to control the processing in the desired manner. When the application returns, the digiseal server compares the return code with the expected success value. If the return code differs, the process returns with an error. Directives and placeholders are used to configure the command line needed to call the external application. Directives: EXITCODE, APP, SET Placeholders: INPUT_FILE_DIR, OUTPUT_FILE_DIR, TMP_FILE_DIR, INPUT_FILE_PATH, INPUT_FILE_PATHES, INPUT_FILE_COUNT, INPUT_FILE_FILENAME, INPUT_FILE_EXT, INPUT_FILE_FILENAME_AND_EXT, ERROR_FILE_PATH Sample: Configuring the command line call "C:\Program Files\dsPDFlibrary\dspdftool.exe" -a XYZKEY pdf2pdfa "C:\in\01.pdf" "C:\out\01.pdf" and the expected success return code 0 using the directives and placeholders leads to the following notation EXITCODE == 0 APP -a XYZKEY pdf2pdfa "$(INPUT_FILE_PATH)" "$(OUTPUT_FILE_DIR)\$(INPUT_FILE_FILENAME_AND_EXT)" The directives and the placeholders are explained in the following tables and the sample in the next chapter.

40 Page 40 of 57 Table 4: Description of the directives. Directive EXITCODE Description Sample EXITCODE defines the expected return code of the application in case of success. The result of the application will be handled as an error, if the application returns with a different code. The command accepts the following comparison operators: <, >, == or!=. and a number. If the EXITCODE is not set the default value 0 is expected. Sample: EXITCODE == 0 The application return 0 in case of success. APP APP indicates the call of the chosen application. The statements after APP are used to configure the command line for the application. After the execution of the application the return code will be compared with the previously set EXITCODE. SET OUTPUT_FILE SET OUTPUT_FILE is an optional directive. It is not needed when only one output file is generated or the custom task is running stand-alone within the process. SET OUTPUT_FILE is used to determine a file as an output file of the custom task. For each custom task call the digiseal server generates an empty working directory OUTPUT_FILE_DIR. All files that are placed within this directory are recognized as the output of the custom task. Using SET OUTPUT_FILE will declare the specified file as the output of the custom task and will create a copy in the output directory. Additionally an output number can be assigned. The output number is important, if the custom task is followed by another task (signing, timestamping, encrypting) within the process. In this case the output file with the output number 1 will be handed over as the input for the following task. OUTPUT_FILE matches OUTPUT_FILE_1. If multiple files have to be declared as output files the numbering continues (OUTPUT_FILE_2, OUTPUT_FILE_3, ). The call gets the file path of the file that is declared to be tan output file: SET filepath OUTPUT_FILE. Sample: SET "$(TMP_FILE_DIR)\1.tmp" OUTPUT_FILE SET "$(TMP_FILE_DIR)\1.tmp" OUTPUT_FILE_1 SET "$(OUTPUT_FILE_DIR)\$(INPUT_FILE_FILENAME_AND_EXT)" OUTPUT_FILE

41 Page 41 of 57 Description of the placeholders Placeholders are always marked as $(placeholder). Sample: $(INPUT_FILE_PATH) The expansion of the placeholders will replace them by their actual values. The digiseal server does not automatically escape or quote the values of the placeholders. The placeholders can be used with the directives APP and SET. Table 5: Description of the placeholders for the command line. Placeholders for the command line INPUT_FILE_DIR Description Sample Input directory C:\in OUTPUT_FILE_DIR Output directory All output files of the external program have to be saved to this working directory. C:\out TMP_FILE_DIR Temporary directory Temporary files can be saved to this directory. They will be erased after each custom task invocation. C:\tmp INPUT_FILE_PATH INPUT_FILE_1_PATH INPUT_FILE_2_PATH INPUT_FILE_PATH is the first input file, equivalent to INPUT_FILE_1_PATH If more input files are given, the filenames with extensions are available as INPUT_FILE_2_FILENAME_AND_EXT,. C:\dir\sample_1.txt INPUT_FILE_PATHS Input files "C:\dir\sample_1.txt" "C:\dir\sample_2.txt" INPUT_FILE_COUNT Number of input files 1 INPUT_FILE_FILENAME_AND_EXT INPUT_FILE_FILENAME_AND_EXT is the first filename with file extension, equivalent to INPUT_FILE_1_FILENAME_AND_EXT. If more input files are given, the filenames with extensions are available as INPUT_FILE_2_FILENAME_AND_EXT,. sample_1.txt INPUT_FILE_FILENAME INPUT_FILE_1_FILENAME INPUT_FILE_2_FILENAME INPUT_FILE_FILENAME is the first filename without extension, equivalent to INPUT_FILE_1_FILENAME. If more input files are given, the filenames are available as INPUT_FILE_2_FILENAME,. sample_1 INPUT_FILE_EXT File extension txt ERROR_FILE_PATH Path to an optional file in which the program may write its error information. C:\err\error_log.txt

42 Page 42 of Sample configuration of return code and command line The digiseal server is calling the external program running within the custom task by invoking the application with a customized command line. The following sample helps to understand: the rules for building the command line using the directives and placeholders and how to declare the expected return code in case of success. The application dspdftool.exe is taken as an example. This application can be used to convert PDF documents to PDF/A conform documents. To do so, the application ("C:\Program Files\dsPDFlibrary\dspdftool.exe") can be called with the command line handing over the arguments for the license key (-a XYZKEY), the type of conversion (pdf2pdfa), the input file ("C:\in\01.pdf") and the output file ("C:\out\01.pdf"). Command line call: "C:\Program Files\dsPDFlibrary\dspdftool.exe" -a XYZKEY pdf2pdfa "C:\in\01.pdf" "C:\out\01.pdf" For the call the following information is needed: application "C:\Program Files\dsPDFlibrary\dspdftool.exe" argument license key -a XYZKEY argument type of conversion pdf2pdfa argument input file "C:\in\01.pdf" argument output file "C:\out\01.pdf" In case of success the application returns with the code 0 : return code for success 0 All information needed for the call has to be configured using the directives and the placeholders (see previous chapters). The directive APP stands for the external application that is called during the custom task. The arguments for the license key and the type of conversion are not replaced and remain as they are. The placeholder $(INPUT_FILE_PATH) is used as the argument for the input file. To configure the argument for the output file, the placeholder for the filename with file extension $(INPUT_FILE_FILENAME_AND_EXT) and the placeholder for the output dictionary $(OUTPUT_FILE_DIR) are concatenated to the following expression for the absolute path "$(OUTPUT_FILE_DIR)\$(INPUT_FILE_FILENAME_AND_EXT)". Using the directives and the placeholders to configure the command line call "C:\Program Files\dsPDFlibrary\dspdftool.exe" -a XYZKEY pdf2pdfa "C:\in\01.pdf" "C:\out\01.pdf" and the expected success return code 0 leads to the following notation: EXITCODE == 0 APP -a XYZKEY pdf2pdfa "$(INPUT_FILE_PATH)" "$(OUTPUT_FILE_DIR)\$(INPUT_FILE_FILENAME_AND_EXT)"

43 Page 43 of Log / Archive tab In the upper section of the Log / Archive tab you can specify the log file for digiseal server. The log file documents the signature processes in a manner specific to each process (including the signing time, certificate holder, process, file name; see Section 5.1.3, page 25.) If the check box has been enabled, the processed data is archived in the archive directory. By enabling the Creating sub directory for every day check box you can also create a directory structure in the archive directory Using INI files for the detailed configuration of processes The configuration of the processes described here can be dynamically adjusted within a specific scope while using digiseal server. For this purpose, an INI configuration file is incorporated into the process parallel to the input data. This INI file contains other parameters for the Encrypt and Send process tasks. When using the file interface, the INI file must have the same file name as the input file with the additional.ini extension. For example, the INI file belonging to the test.pdf file must be named test.pdf.ini. Both files must be stored in the input directory. Figure 20: Example INI configuration file for controlling the Encrypt and Send process tasks. To control the encryption the INI configuration file must contain an [Encrypt] section. This section contains the Password=abc123 value for password-based encryption or one or several Certificate=C:/Path/Certificate.cer entries for certificate-based encryption. Please note that the otherwise standard back slash "\" has to be replaced with a simple slash "/" in the file path. If the Send process is to be configured via an INI file, the INI file must contain a [Mail] section. Table 6 describes the parameters for the [Mail] section. Table 6: Description of the parameters for the INI configuration file for the [Mail] section. Parameter Subject= To=recipient@firma.de From=sender@firma.de Body=Dear Description subject heading sender recipient Message text for the . Please write the text in a line and use the control characters \r, \r\n or \n to add line breaks in the message text.

44 Page 44 of 57 Host=mail.server.de User=sender Password=abc213 SMTP server address User name of the specified SMTP server Password for the specified user on the SMTP server If the INI file does not contain any information on the host, user or password, the information in the tab is used. The information from the Bcc field in the tab is always used.

45 Page 45 of Signing faxes with a 2D barcode A special application area for electronic signatures is the transmission of signed data by fax. Here the signature and the signed data must be transferred in a printable form to enable it to be reconstructed by the recipient. For this purpose, digiseal server offers the fax signature with which inputted fax data (TIFF) is read in, processed, signed (PKCS#7, *.pk7 file) and transmitted by means of a 2D barcode (matrix code). The result of this signature process task is a TIFF image file that supplements the original document with the generated matrix code. This document can be sent electronically by computer fax and can be verified electronically by the recipient. It is also possible to print out and archive the signature using the matrix code. The recipient reconstructs the data from the matrix code using the verification software (see Section 8.6, page 55). The signature and the signed data are then available to the recipient as an electronic data set. By way of example, Figure 21 shows a fax page with the matrix code. Because the storage capacity of the matrix code is limited, the signature should only be calculated for the area of the fax that contains signature-relevant data. Graphic elements such as the company logo should be omitted in order to reduce the storage requirement. Section 7.2 describes how to control the processing of the inputted fax data. In the case of invoices in Germany, the signature-relevant part must contain all the tax-relevant invoicing information in accordance with Article 14 of the German Value Added Tax Act (UstG). This includes, for example, the complete name and address of both the provider and recipient of the services as well as all other relevant invoicing details. It is not sufficient that this information is noted, for example, in the letterhead if this is not signed Requirements for the input data Signature-relevant data is transmitted as a multi-page TIFF with the following properties: Black / White 1728 pixels per line Fine fax resolution: 203 x 196 dpi Fax-G4 compression 7.2. Processing the input data The processing of the fax input data is aimed at determining the signature-relevant image areas. This is in order to reduce the size of the matrix code, whereby the fax data is processed according to the following scheme (Figure 21): 1. Configuration of an input area with the signature-relevant data in the input data. 2. Configuration of an output area on the output page in which the input and the matrix code are added. 3. Generation of a signature for the input and the generation of the matrix code with the signature and signed data. 4. Integration of the input area and matrix code in the selected output area. The configuration of the parameters is explained in the next section.

46 Page 46 of 57 Figure 21: Processing of fax data: An input area (green) is defined on the input page, which is then signed. The signature and the image data for the input area are stored in the matrix code. The input area and the matrix code are then inserted in the defined output area (brown) on the output page. The input area and the matrix code are normally outputted on the original data (see Figure 21). Section explains how they can be outputted on empty pages or templates Configuring the processing with INI configuration files Using INI configuration files it is possible to pre-process fax data. The aim of the processing is to define those areas of the fax that contain signature-relevant information. This helps to reduce the size of the data that has to be stored in the matrix code. The processing is configured using an INI configuration file. This is either predefined in the 2.3 Signature tab (see Section 6.3, page 30) or is incorporated into the process as an additional input file belong side the fax image file. The INI file is named like the input data, whereby the extension is changed to.ini. An example for such a file pair is: Faxdokument001.tif Faxdokument001.ini Structure of the *ini file with layout information The INI configuration files for controlling the fax processing contain individual sections ([Page1], [Page2] etc.), in which the parameters for the individual pages are specified. The [PageI] section is used to specify parameters for the pages for which no specific sections have been configured.

47 Page 47 of 57 [Page1] ;Section with parameters for page 1 topofinput=48mm leftofinput=22mm bottomofinput=86mm rightofinput=20mm topofoutput=50mm leftofoutput=0mm bottomofoutput=40mm rightofoutput=0mm [PageI] topofinput=20% leftofinput=10% bottomofinput=0% rightofinput=15% ;Section with parameters for remaining pages topofoutput=20% leftofoutput=0% bottomofoutput=0% rightofoutput=0% Figure 22: Example of an INI file for configuring the fax processing in Figure Defining the input and output areas The input and output areas are specified as parameters within the sections. The following parameters are available: topofinput, leftofinput, rightofinput and bottomofinput: Margin from the input area to the respective page edge in mm or percent (%). topofoutput, leftofoutput, rightofoutput and bottomofoutput: Margin from the output area to the respective page edge in mm or percent (%). The margins to the left and right pages edges only affect the image data. The matrix code is always printed across the entire width. One example is the INI file in Figure 22, which contains the configuration for the processing shown in Figure Ignoring input data Pages descriptor attributes in the following form are generally used for specifying areas that are not to be depicted: topofdatatoignore<id>: Distance of the right corner <ID> from the upper page edge leftofdatatoignore<id>: Distance of the right corner <ID> from the left page edge bottomofdatatoignore<id>: Distance of the right corner <ID> from the lower page edge rightofdatatoignore<id>: Distance of the right corner <ID> from the right page edge Any alphanumeric character chain can be used for the <ID> value. Each <ID> value corresponds to a rectangular area of data that is not to be depicted. This provides the possibility to remove any number of rectangular areas from the depiction.

48 Page 48 of Outputting the matrix code on templates (stationery function) Unless other parameters are used, the matrix code and the selected input area are always outputted on the original page (see Figure 21), whereby the output is incorporated into the selected output area. Using the images parameter in the INI file enables another page to be used as the output background. This enables company stationery to be depicted in the fax processing.

49 Page 49 of Appendix 8.1. Overview of usable signature formats The applied signature format has to be configured using the menu 2. Process Configuration -> 2.3. Signature. The following formats are available. The table below contains the explanation of the signature formats. Table 7: Description of the signature formats Signature format CAdES detached / *.p7s Description CAdES detached / *.p7s / signed-data CAdES (CMS Advanced Electronic Signatures) according to ETSI EN (former CMS, PKCS#7 signature) The signature and signature certificate are stored in a separate *.p7s file and can only be verified with the original file. Input data: Any file format CAdES embedded / *.pk7 CAdES embedded / *.pk7 / signed-data CAdES (CMS Advanced Electronic Signatures) according to ETSI EN (former CMS, PKCS#7 signature) The signature object, signature and signature certificate are stored together in a *.pk7 file. *.pk7 can be converted into *.p7s. Input data: Any file format CAdES embedded / *.p7m CAdES embedded / *.p7m / S/MIME multipart-signed CAdES (CMS Advanced Electronic Signatures) according to ETSI EN (former CMS, PKCS#7 signature) The *.p7m format is an expansion of the *.pk7 format. The data is processed as a MIME message Input data: Any file format