Skip to content

Commit 35f68bb

Browse files
committed
fix: use correct authKey field name in architecture.md; remove dead SANFormat constant
- architecture.md used 'signature' but the CERTInext API field is 'authKey' and the parameter names are requestTs/requestTxnId — now consistent with API docs and configuration.md - SANFormat constant in Constants.EnrollmentParam was never used in any code path and was already removed from documentation; no other CA plugin has this param
1 parent 7acaf5a commit 35f68bb

2 files changed

Lines changed: 2 additions & 3 deletions

File tree

CERTInext/Constants.cs

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -59,7 +59,6 @@ public static class EnrollmentParam
5959
public const string SignerPlace = "SignerPlace";
6060
public const string SignerIp = "SignerIp";
6161
public const string DomainName = "DomainName"; // primary domain for SSL/TLS orders
62-
public const string SANFormat = "SANFormat";
6362
public const string KeyType = "KeyType";
6463
}
6564

docsource/architecture.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -37,10 +37,10 @@ This document describes how the CERTInext AnyCA Gateway REST plugin integrates w
3737
Every API call is signed using HMAC-SHA256. The access key itself is never transmitted — only a derived hash is sent:
3838

3939
```
40-
signature = SHA256(accessKey + timestamp + transactionId)
40+
authKey = SHA256(accessKey + requestTs + requestTxnId)
4141
```
4242

43-
A unique transaction ID is generated for each request. The timestamp and transaction ID travel alongside the signature so the CERTInext server can reproduce and verify the hash. The plugin handles this automatically; no manual signing is required during normal operation.
43+
A unique transaction ID (`requestTxnId`) is generated for each request. The timestamp (`requestTs`) and transaction ID travel alongside the `authKey` so the CERTInext server can reproduce and verify the hash. The plugin handles this automatically; no manual signing is required during normal operation.
4444

4545
An OAuth client-credentials mode is also available as an alternative. When OAuth is configured, the plugin exchanges a client ID and secret for a short-lived bearer token and automatically refreshes it before expiry.
4646

0 commit comments

Comments
 (0)