Zertifikatsverwaltung

Zertifikatsverwaltung

Beim Starten der Zertifikatsadministration erscheint eine Übersicht über alle installierten öffentlichen und privaten Schlüssel. Das Symbol in der ersten Spalte zeigt dabei an, ob es sich um einen privaten Schlüssel () oder einen öffentlichen Schlüssel () handelt. Die Spalte Alias beinhaltet den hinterlegten Identifier für den jeweiligen Schlüssel. Gerade für die ausgehende Crypto-Verarbeitung ist die Korrektheit des Alias entscheidend. Die im Zertifikat hinterlegte Email-Adresse wird beim Import in dem Feld E-Mail gespeichert. Falls die Mail-Adresse nicht aus dem Zertifikat ausgelesen werden konnte, kann sie auch nachträglich hinzugefügt werden (über den Button Alias ändern). Die Spalten Zeitscheibe von und Zeitscheibe bis bieten neben den Spalten Gültig von und Gültig bis eine Übersicht über den Verwendungszeitraums eines Zertifikats. Während die Gültigkeit durch das Zertifikat selbst bestimmt ist, kann der Verwendungszeitraum über die Zeitscheiben davon abweichend konfiguriert werden (z.B. um den Zeitraum weiter zu reduzieren). Die Spalte Verwendung für zeigt auf einen Blick, ob der jeweilige Schlüssel für die Signatur bzw. Verschlüsselung verwendet werden soll. Falls es für einen Marktpartner hierfür unterschiedliche Schlüssel geben sollte, kann hier über den Verwendungszweck differenziert werden. Die durch den Gültigkeitszeitraum vorgegebenen verbleibenen Tage können in der Spalte Verbleibene Tage eingesehen werden. Über die Spalte Aktiv kann der Benutzer darauf Einfluss nehmen, ob ein Zertifikat überhaupt genutzt werden soll oder nicht. Ein deaktiviertes Zertifikat wird weder für die Ver- bzw. Entschlüsselung verwendet noch für den Signaturprozess. Die Spalte Status fasst in einer Farbe zusammen, ob ein Zertifikat noch gültig ist (grün) bzw. abgelaufen (rot) bzw. kurz vor Ende des Gültigkeitszeitraumes (orange). Ein gültiges, aber deaktiviertes Zertifikat wird gelb angezeigt. Die Spalte Beschreibung zeigt einige aus dem Zertifikat extrahierten Daten an, wie z.B. den Herausgeber des Zertifikats. Die Spalte Sperrliste zeigt an, ob ein Zertifikat vom Aussteller gesperrt worden ist.

Im Modul des Security Servers ist es möglich, neue Zertifikate hochzuladen, die Ansicht zu Aktualisieren, Zertifikate zu löschen, sowie den Alias (also standardmäßig die ILN des Marktpartners) zu ändern. Ferner können die Sperrlisten aktualisiert werden.

 

Beim Upload neuer Zertifikate kann gewählt werden, ob diese zur Signatur oder zur Verschlüsselung genutzt werden sollen. Beim Ändern des Alias kann außerdem die Zeitscheibe und die Einstellung, ob Signatur oder Verschlüsselung genutzt wird, geändert werden.

Außerdem können die gesamten Zertifikate als CSV sowie als Keystore exportiert werden.

Certificate Upload

You need to upload your certificates and private keys*. Using the Upload button, you will receive the upload dialog.

After choosing a file, this can be a certificate, private key or even a java keystore, you will see some additional fields. Usage defines (only for certificates and keystore) if the certificates should be used for encryption or verification or both. Private keys will always be used for decryption and signature.

You need to add an alias (MPID or email, if you integrate it into B2B by Practice), if you are uploading single certificates or private keys. If you upload keystores, email is used as alias.

If you upload a keystore, you need to provide the keystore password, too!

Before the certificate is stored, it is validated. The result of validation is presented to you. The certificates of a keystore are validated in less detail.

The same certificate must not be uploaded with the same alias twice.

“Check for Duplicate” checks whether the given certificate has already been uploaded. If you want to avoid to upload duplicates, you can activate this check. This check works for certificates and keystores.

The term “private key” refers to the combination of a private key and the corresponding certificate. A private key is stored together with its certificate.

Follow Certificates

The column “follow certificate” indicates whether there exists another certificate that can substitute the current certificate after it has exceeded its timeslice. The entry in this column is called followerState.

There are 4 different followerStates possible: OVERLAP, GAPLESS, GAP, and NONE. They are computed in the given order.

Let certificate a be the certificate of the table row and let certificate b be the potential follower. The timeslice of a certificate is denoted as [from,to].

OVERLAP: There exists a certificate b with same alias as certificate a and overlapping timeslice.

a.alias = b.alias and a.to < b.to and a.to > b.from

GAPLESS: There exists a certificate b with same alias as certificate a and a timeslice that starts right when the timeslice of certificate a ends.

a.alias = b.alias and a.to < b.to and a.to = b.from

Note: a.to must be equal to b.from. Even a difference by one second does not fit this state.

GAP: There exists a certificate b with same alias as certificate a and its timeslice starts after the timeslice of certificate a ends.

a.alias = b.alias and a.to < b.to and a.to < b.from

NONE: Otherwise. There is no certificate with same alias, or any potential follower certificate b has a timeslice, that ends before timeslice of certificate a ends.

a.alias != b.alias or a.to >= b.to

You may want to configure a GAPLESS follow certificate. If a certificate has state NONE you have to upload a follow certificate. If a certificate has state GAP, you can try to increase the timeslice or to upload another follow certificate (since the timeslice cannot be greater than the validity). If a certificate has state OVERLAP, it suffices to decrease the timeslice. Timeslice changes can be applied to both the current and the follow certificate.

Search by QuickFilter

It is possible to select ceritifcates by quickfilter.

It is possible to select by private or public key or active/inactive certificate and it is possible to search by string in textual fields.

The search within the textual fields can also be inverted by a ! or NOT analogue to the messagemonitor. Additional it is possible to search with regex-expressions.

Example

  • Search the aliases e.g. with ago|rsc (analogue for email)

See also: search in messageMonitor

Automatic Certificate Import

You can configure the FSS to import certificates from emails. These mails are the Inbound Market-Messages, carrying Edifact attachments. An email contains the certificate if it has been signed.

To activate the feature you must configure the following FSS start argument:

set JAVA_OPTS=-Dauto.sign.cert.import.from.mail="true"

If the certificate, that has signed the inbound mail, is not known in the FSS, it is imported if it holds:

  • the issuer certificate is known
  • the certificate is used during its validity period
  • the alias can be determined, based on the certificate or based on the mail sender

The certificate is not imported again, if it has already been stored but has been deactivated.

For the imported certificate holds:

  • timeslice = now until validity-end (more details compare next section)
  • the description has the prefix AUTO-IMPORT

Automatic certificate import is not supported for AS2.

Timeslice & Validity

Remember:

Validity is used for on incoming messages. Validity of two following certificates must overlap by two weeks. Validity is a property of the certificate itself and cannot be changed after the certificate has been created.

Timeslice is used for outgoing messages. Timeslice of two following certificates must neither overlap, nor must there be a gap in between. Timeslice is a property that can be configured in the FSS Certificate Manager. The maximum possible timeslice is the validity.

Timeslice start configuration

For the timeslice start of the imported certificate holds:

import.slice.start = now

This is since the partner already used his certificate, and thus the 2 weeks overlap have already started (expecially the validity cannot be violated, otherwise the import would fail). Therefore we can start using the certificate safely. On the other hand, the predecessor must be adapted:

Let the predecessor be the certificate with same alias, that is active right before the imported certificate. If it exists, and if its slice is still active, the timeslice of the predecessor is adapted:

predecessor.slice.end = import.slice.start

Timeslice end configuration

For the timeslice end of the imported certificate holds in most cases:

import.slice.end = import.validity.end

Thus the certificate is used for the longest time possible.

Let the follower be the certificate with same alias, that becomes active next after the imported certificate. In most cases the follower does not exist yet, but if it exists, and if its slice is active before the imported certificate expires, it holds:

import.slice.end = follower.slice.start

Thus there is neither overlap time nor a gap in between both certificates.

View Me   Edit Me