---
title: Certificate Management
description: "How FileRelay handles ArchiveLink certificates for signature verification of inbound SAP requests."
---

# Certificate Management

ArchiveLink has a built-in certificate exchange mechanism — when SAP wants to establish trust with a content server, it sends its system certificate using the `putCert` command:

```
POST /ContentServer?contRep=Z1&pVersion=0047&command=putCert
Content-Type: application/octet-stream

[certificate binary data]
```

FileRelay receives the cert, stores it, and ties it to the source identified by `contRep`. **No manual file uploads** — the whole exchange happens over the protocol.

## Sending certs from SAP

Two paths:

- **Automatic** — when you create a content repository in OAC0 and test the connection, SAP often sends its certificate automatically. Depends on SAP version + config.
- **Manual via CSADMIN** — open `CSADMIN` → select the repository → **Send Certificate**. Verify it appears in the FileRelay dashboard under the source.

> **REPLACE:** Screenshot of the CSADMIN certificate send action

## Viewing certificates

Source detail page → **Certificates** section. Each entry shows: Subject (typically the SAP system ID), Issuer, Valid From/To, Status, SHA-256 Fingerprint.

> **REPLACE:** Screenshot of the certificates list

## Active vs Inactive

Toggle individually:

| State | Behaviour |
|---|---|
| Active | Used for signature verification when verification is on |
| Inactive | Ignored during verification |

Useful for rotation — add the new cert, verify it works, deactivate the old one. No interruption.

## Signature verification

Per-source setting. Off by default — handy during setup and testing.

When **enabled**, every `create`, `update`, and `delete` request must carry a valid signature matching one of the active certificates. Anything else gets rejected.

**Enable when** the FileRelay endpoint is internet-reachable, you want to constrain who can post documents, or your security policy requires authenticated requests.

**Leave disabled when** you're in initial setup, your network already isolates the endpoint (VPN, private link), or you're troubleshooting connectivity.

## Expiration

FileRelay does **not** automatically block on expiry — behaviour depends on whether verification is on:

- Verification **on** + expired cert → signatures can't validate; SAP must send a renewed cert before the old one expires.
- Verification **off** → expiration has no impact on document flow.

### Handling renewal

1. Watch the **Valid To** dates in the dashboard.
2. Regenerate the SAP system cert if needed (transaction `STRUST`).
3. `CSADMIN` → **Send Certificate** to push it.
4. Activate the new cert in FileRelay.
5. Deactivate the old once confirmed working.

## Multiple certificates

A source can hold many certs at once. Useful for:

- **Rotation overlap** — add new before removing old.
- **Multiple SAP systems** writing to the same repository (uncommon).
- **Test alongside prod** certs.

During verification, FileRelay matches the request signature against **every** active certificate for the source. Any match accepts.

## Troubleshooting

| Symptom | Check |
|---|---|
| "Signature Verification Failed" | Cert in FileRelay matches what SAP sent; status is Active; not expired; try re-sending from `CSADMIN`. |
| Cert doesn't appear after send | `contRep` matches the source's repo ID; source exists and is active; check workspace activity log. |

## Next steps

- [Sources Overview](/docs/sources/overview)
- [Transaction OAC0 Guide](/docs/sources/oac0)
- [SAP ArchiveLink Setup](/docs/sources/archivelink)