|
Barracuda Application Server C/C++ Reference
Native APIs, integration guides, and platform interfaces
|
SharkTrustX-psa.vcxproj builds the native C example with persistent PSA keys. It uses the same enrollment, ACME, renewal, and certificate checks as the original example. The original example.vcxproj remains the non-PSA build. This simulator is for development; it does not provide hardware key protection.
Use a Visual Studio developer command prompt in this directory. Supply your ACME contact email with the ExampleEmail MSBuild string property. Its default is empty, which retains the example's compile-time contact-email requirement. You can also add this property under UserMacros for interactive VC++ builds.
Debug and Release are supported on Win32 and x64. The executable is SharkTrustX-psa.exe; output and intermediate directories are separate from the original example. The Visual Studio debugger uses the output directory. For command-line launches, use that directory as shown above.
The existing tokengen.c selects the portal and zone. The public example uses Let's Encrypt staging; its certificates are intentionally not browser-trusted. HTTP status uses port 8080 and HTTPS uses port 8443 once a certificate is ready. For SharkCA, set the existing integer MSBuild property SHARKTRUSTX_PRIVATE_CA=1 and use your private portal's token generator and appropriate outbound trust anchor, as described in the main example guide. Both the original and PSA examples trust the self-signed ECC ISRG Root X2 for outbound HTTPS. The current portal and ACME ECC chains can terminate at X2 without RSA-4096 verification. The client's own account and certificate keys remain P-256. Other portals or ACME servers may require a different trust store; hostname and certificate validation remain enabled.
Mako's HTTPS client loads a larger CA bundle that also includes X2. The simulator retains RSA-4096 public verification for other applications; private RSA operations remain limited to 2048/3072 bits.
The test initializer, examples/misc/PsaSimulator.c, is shared with Mako and Xedge. It creates psa-simulator/ beside the executable and keeps its random 32-byte wrapping secret in the separate psa-simulator.key file. Both use protected owner-only Windows permissions. Later starts reuse this store and secret. The helper also provisions Mako's test roots 1 and 2; this C client does not use or remove those roots.
SHARKTRUSTX_PSA_KEY_BASE is an optional integer preprocessor definition, default 0x23545800, with range 1 through 0x3ffffffd. Reserve that ID and the following two IDs exclusively for one SharkTrustX private state store: the account key and two alternating certificate keys. All are persistent P-256 signing keys without private-key export permission. A newly issued certificate uses a fresh key. The previous key remains valid while its TLS context is active and is retired after successful replacement.
The state journal records generation intent before creating a key. Restart discards an interrupted candidate while retaining the installed identity. Missing or mismatched saved keys cause an error; they are not silently regenerated. Partial cleanup retains the SharkCA account binding, while public CA partial cleanup removes it. Full cleanup removes all keys owned by the client, leaving unrelated provider keys intact. Interrupted cleanup retains its reset marker until retry succeeds.
Keep sharktrustx.0, sharktrustx.1, and any sharktrustx.reset file private. They contain enrollment credentials even though PSA private keys are absent. PSA and native state formats differ. Do not copy native state into this build or remove state files to reset enrollment; use SharkTrustX_clean() so owned keys are retired too. Corrupt state or provider records require repair before cleanup can establish key ownership. No automatic migration is supplied.