Skip to end of metadata
Go to start of metadata

Basic information

The plugin contains an action for creating a qualified or an unqualified electronic signature. Inserting a signature is possible thanks to the mechanism provided by the Szafir SDK Web Module component - a library that enables the integration of electronic signature functionality into applications and systems that use a web browser interface to communicate with the user.

Requirements

System version required PWFL: 4.0.19

Plugin version required PWE: 4.0.13

Plugin version required Plugin Configuration Manager: 4.0.0

Certificate configuration

In order to be able to use the plugin components that are based on the operation of the Szafir application, it is necessary to define the configuration file in the plugin configuration management panel (PCM - Plugin Configuration Manager) in the Plus eSignature tab. This file contains the certificate store, cryptography provider definitions, timestamp server-related settings, network settings, and other parameters that affect the plugin's operation. After installing the plugin in the system, a file with the default certificate configuration called settings_cryptoproviders is created in the PCM. You can edit this configuration and add your own certificate configuration. All configuration files are stored in XML format.

 

 Configuration of the certificate store

The certificate store is available in the form of the <LocalStore> tag. This tag contains elements with Base64 encoded certificates of certification service providers <CACertificate> and HTTP / HTTPS / LDAP addresses pointing to entities providing information on the validity of certificates in the form of CRL lists or OCSP responses.

<LocalStore>
 
<CACertificate><!-- [ 02 ] PL
	VALIDITY: 2002-06-11 => 2027-06-11
	SUBJECT : C=PL; O=Unizeto Sp. z o.o.; CN=Certum CA
	ISSUER  : C=PL; O=Unizeto Sp. z o.o.; CN=Certum CA
	SERIAL  : 010020
--><X509Certificate>
MIIDDDCCAfSgAwIBAgIDAQAgMA0GCSqGSIb3DQEBBQUAMD4xCzAJBgNVBAYTAlBMMRswGQYDVQQKExJVbml6ZXRvIFNwLiB6IG8uby4xEjAQBgNVBAMTCUNlcnR1bSBDQTAeFw0wMjA2MTExMDQ2MzlaFw0yNzA2
MTExMDQ2MzlaMD4xCzAJBgNVBAYTAlBMMRswGQYDVQQKExJVbml6ZXRvIFNwLiB6IG8uby4xEjAQBgNVBAMTCUNlcnR1bSBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM6xwS7TT3zNJc4YPk/E
jG+AanPIW1H4m9LcuwBcsaD8dQPugfCI7iNS6eYVM42sLQnFdvkrOYCJ5JdLkKWoePhzQ3ukYbDYWMzhbGZ+nPMJXlVjhNWo7/OxLjBos8Q82KxujZlakE403Daaj4GIULdtlkIJ89eVgw1BS7Bqa/j8D35in2fE
7SZfECYPCE/wpFcozo+47UX2bu4lXapuOb7kky/ZR6By6/qmW6/KUz/iDsaWVhFu9+lmqSbYf5VT7QqFiLpPKaVCjF62/IUgAKpoC6EahQGcxEZjgoi2IrHu/qpGWX7PNSzVttpd90gzFFS269lvzs2I1qsb2pY7
HVkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAuI3O7+cUus/usESSbLQ5PqKEbq24IXfS1HeCh+YgQYHu4vgRt2PRFze+GXYkHAQaTOs9qmdvLdTN/mUxcMUbpgIKumB7bVjC
mkn+YzILa+M6wKyrO7Do0wlRjBCDxjTgxSvgGrZgFCdsMneMvLJymM/NzD+5yCRCFNZX/OYmQ6kd5YCQzgNUKD73P9P4Te1qCjqTE5s7FCMTY5w/0YcneeVMUeMBrYVdGjux1XMQpNPyvG5k9VpWkKjHDkx0Dy5x
O/fIR/RpbxXyEV6DHpx8Uq79AtoSqFlnGNu8cN2bsWntgM6JQEhqDjXKKWYVIZQs6GAqm4VKQPNriiTsBhYscw==</X509Certificate>
	<CRLAddress>https://crl.certum.pl/ca.crl</CRLAddress>
</CACertificate>
 
...
 
</LocalStore>
 Generating a software certificate and connecting it to the configuration file

In order to use a software (non-qualified) certificate, you need to generate your own certificate and place a reference to it along with the public key in the settings_cryptoproviders configuration file.

  1. To programmatically generate your own certificate, you must have java (jre or jdk) installed on your computer. Enter the bin directory, e.g. d:\PlusWorkflow\Java\jdk1.8.0_161\bin\ and run the command:

    keytool -genkeypair -keystore certyfikat.p12 -storetype PKCS12 -storepass suncode -alias certyfikat -keyalg RSA -keysize 2048 -validity 99999 -dname "CN=Imie Nazwisko, O=Suncode, L=Poznan, ST=Wlkp, C=PL"
  2. To retrieve the public key from the generated certificate, run the following command:

    keytool -exportcert -keystore certyfikat.p12 -storepass suncode -alias certyfikat -rfc -file public-certificate.pem
  3. In order to connect the generated certificate to the settings_cryptoproviders configuration file, add the public key in the sections: <CACertificate> <X509Certificate>

    <!--
    <LocalStore>
    ...
    -->
    <CACertificate>
        <X509Certificate>
            {tekstowa zawartosc pliku public-certificate.pem}
        </X509Certificate>
        <CRLAddress>http://crl.omniroot.com/ctglobal.crl</CRLAddress>
    </CACertificate>
    <!--
    ...
    </LocalStore>
    -->
  4. And then in the <SoftwareProvider> section, add an indication of the previously generated certificate:

    <!--
    <CryptoProviders>
    ...
    -->
    <SoftwareProvider>
        <Name>PKCS#12</Name>
        <URI>file:///d:/Certyfikaty/certyfikat.p12</URI>
    </SoftwareProvider>
    <!--
    ...
    </CryptoProviders>
    -->

    Warning

    The password provided when generating the certificate in the storepass (suncode) parameter is the PIN that should be entered when signing the documents.

 CRL list configuration

CRL addresses for individual certificates are contained in the <CRLAddress> tag located in the <CACertificate> container. For each entity, it is also possible to include addresses with historical CRLs, using the <HistoricalCRLAddress> element behind the <CRLAddress> element. Each of the CRL locations must be written in a form compatible with the URI. If the CA does not support CRL, set the value to <CRLAddress>NO_CRLDISTRIBUTIONPOINT</CRLAddress>.

 Configuration of the OCSP service

Indicating the address of the OCSP service for individual certification authorities is done through the <OCSPAddress> tag, placed after the elements pointing to the CRL lists in the <CACertificate> container. The location of the OCSP service must be written in a URI compliant form (HTTP/HTTPS). Additionally, the <LocalStore> section must be followed by an entry <UseOCSPOverCRL>true</UseOCSPOverCRL>; in its absence, the Szafir SDK components will use CRL lists. If the OCSP service is unavailable, CRLs will be used.

 Configuration of certificates for signing

The <Signing> section allows you to select the appropriate type of certificate or directly the certificate used to create the electronic signature by filtering the remaining certificates. By default, there is no restriction on the certificate (<AnyCertificate>). There are also options:

  • <AnyQualifiedCertificate> - any qualified certificate
  • <AnyNonQualifiedCertificate> - any unqualified certificate
  • <OneCertificate> - one certificate, identified with <Issuer> (issuer in the form of DN, after commas) and <Serial> (serial number in the form of DEC - decimal - you can read it with Szafir directly or from Windows, converting from HEX to DEC using a Windows calculator).
<Signing>
    <SigningCertificate>
        <OneCertificate>
            <Issuer>organizationIdentifier=VATPL-5260300517,CN=COPE SZAFIR -Kwalifikowany,O=Krajowa Izba Rozliczeniowa S.A.,C=PL</Issuer>
            <Serial>Certificate_serial_number_in_the_form_of_the_DEC</Serial>
        </OneCertificate>
    </SigningCertificate>
</Signing>
 Time stamping service configuration

Time stamping service parameters are configured in the <TimeStamping> tag. The <TimeStampingCertificate> tag, like <SigningCertificate>, specifies the type of certificate used to sign the timestamp request. Marking request sometimes it is signed to identify the subscriber to the service. You can disable the signing of time stamping requests by setting the Authorization = "false" attribute of the <TimeStamping> tag. Support for the process of time-stamping documents with a time stamp issued by KIR is guaranteed. When using the KIR S.A. time stamping services, the Authorization attribute must have a default value of "true". The <Host> tag specifies the address of the time stamping service. Commenting the <TimeStamping> section blocks the service usage.

<TimeStamping Authorisation="true">
    <TimeStampingCertificate>
        <AnyCertificate />
    </TimeStampingCertificate>
    <!-- KIR Szafir TSA -->
    <Host>http://www.ts.kir.com.pl/HttpTspServer</Host>
    <!-- Certum Public QLTS -->
    <!-- <Host>http://public-qlts.certum.pl</Host> -->
    <!-- CUZ Sigillum QTSA1 -->
    <!-- <Host>http://tsa.sigillum.pl</Host> -->
</TimeStamping>
 Configuration of cryptography providers

Cryptography providers are configured in the <CryptoProviders> tag section. Communication with cryptographic devices (cryptographic card or HSM cryptographic module) takes place using the PKCS#11 interface and the <HardwareProvider> tag is used. In the existing settings_cryptoproviders configuration, a hardware cryptography provider is defined by default to support CryptoTech Carbon, CryptoTech Graphite and CryptoTech CloudSigner cryptographic cards.

<CryptoProviders>
  
<!-- PKCS11 KIR Carbon -->
 
<HardwareProvider>
    <Name>PKCS#11 Type A</Name>
    <URI>CCP11s.dll</URI>
</HardwareProvider>
 
<!-- PKCS11 KIR Graphite -->
 
<HardwareProvider>
    <Name>PKCS#11 Type A</Name>
    <URI>CCGraphitep11.dll</URI>
</HardwareProvider>
 
<!-- PKCS11 KIR mSzafir -->
 
<HardwareProvider>
    <Name>PKCS#11 Type A</Name>
    <URI>file:///c:/Program%20Files/CryptoTech/CryptoCard/CloudSignerP1164.dll</URI>
</HardwareProvider>
<HardwareProvider>
    <Name>PKCS#11 Type A</Name>
    <URI>file:///c:/Program%20Files%20(x86)/CryptoTech/CryptoCard/CloudSignerP11.dll</URI>
</HardwareProvider>
  
</CryptoProviders>

 

It is possible to use many different cryptography providers by specifying multiple <HardwareProvider> tags.

 

The PKCS # 12 public key cryptography standard allows the use of .p12 or .pfx files that store the private key and certificates. This variant is defined using the <SoftwareProvider> tag.

<CryptoProviders>
  
<SoftwareProvider>
    <Name>PKCS#12</Name>
    <URI>file:///c:/example.p12</URI>
</SoftwareProvider>
</CryptoProviders>

 

Cryptography provider URIs must contain URI-compliant entries. Currently, URIs pointing to local files (file:///) and network resources (http:// and https://) are supported for cryptography providers. It is possible to use relative URIs, but remember to put the libraries in the path shown under System.getProperty ("java.library.path") in the Java Virtual Machine.

 

For the library in the PKCS#12 standard, an alternative form of specifying the URI path is to specify the entire file in Base64 encoded form.

<SoftwareProvider>
    <Name>PKCS#12</Name>
    <Base64Binary>JVBERi0xLjQKJdPr6eEKMSAwIG9iago8PC9UaXRs</Base64Binary>
</SoftwareProvider>
 The use of qualified certificates in a different operating mode than the native Szafir window

Szafir SDK components by default do not allow the use of qualified certificates in a mode of operation other than the native Szafir window. However, if Integrator wants to implement its own data presentation method, it can use qualified certificates using a different operating mode than the Szafir window by setting the <AllowNonWindowForQC> tag file as follows.

<Settings>
    …
    <Algorithms>……..</Algorithms>
    <AllowNonWindowForQC>true</AllowNonWindowForQC>
</Settings>
File with the default configuration of the certificate to download
System parameters

Installing the plugin in the system results in the creation of two system parameters in the Plus eSignature category.

Nazwa parametruOpis
MaximumNumberOfFilesSpecifies the maximum number of files allowed to be signed by the Szafir module within one call of the Szafir Web Module mechanism.
MaximumSizeOfFilesSpecifies the maximum allowable size of files submitted for signing by the Szafir module within one call of the Szafir Web Module mechanism. File size is specified in MB.
Signature versions
Signature versionDescription
BES

Signature-only variant used for short-term valid documents. After the certificate with which the document was signed has expired, cryptographic verification of the document is possible, but it may not be possible to verify the validity of the signing certificate. Signature verification is possible on a current basis - then if the certificate has expired, the verification will be negative, or for the time indicated by the user - then the verification result will depend on the validity status of the certificate at the given time. The following formats supported by Szafir SDK are compatible with the BES variant:

  • XAdES-BES,
  • EPO-XAdES-BES
  • CAdES-BES,
  • PKCS#7,
  • PAdES-BES
  • ASIC-S-XAdES-BES
  • ASIC-S-CAdES-BES
T

BES variant, additionally containing a timestamp, which is a proof that the signature and the signing certificate existed or was valid at a given time. The validity of the signature in the T variant is determined by the validity of the certificate of the time stamping authority. The following formats supported by Szafir SDK are compatible with the T variant:

  • XAdES-T,
  • EPO-XAdES-T
  • CAdES-T,
  • PKCS#7-T,
  • PKCS#7 with Time
  • PAdES-T
  • ASIC-S-XAdES-T
  • ASIC-S-CAdES-T
LTV/A

The signature in this variant includes the signature timestamp, a full set of certificates with a complete certification path, CRL/OCSP responses, certifying the validity of the signing certificate and additional time stamping of all these elements. This variant is used for signatures with long-term validity that are intended to be of long-term evidential value. In this variant, signatures should be systematically refreshed by the end of the validity period of the certificate of the time stamping authority by subsequent time stamping, triggering the verification process with the use of REFRESH formats. The following formats supported by Szafir SDK are compatible with the LTV/A variant:

  • XAdES-A,
  • EPO-XAdES-A
  • PAdES-LTV
  • PAdES-LTV-REFRESH
  • XAdES-A-REFRESH
  • EPO-XAdES-A-REFRESH
Signature formats
Signature formatDescription
CAdESDefined by the ETSI TS 101 733 standard, based on the PKCS7/CMS format. Files of this format are binary.
XAdESDefined by the ETSI TS 101 903 standard, based on the XML/XMLDSig format. Files saved in the XAdES format are XML files.
PAdESDefined by the ETSI TS 102 778 standard, allowing to save a signature in a PDF file in such a way that it is possible to open a given PDF file in Adobe Reader and verify the integrity of the signed document.
ASICDefined by the ETSI TS 102 918 standard. ASIC files are containers for data and signatures. They have the structure of ZIP files.
Available components
Actions
NameVersionDetails
Signing documents

1.0.0

More information...

  • No labels
Write a comment…