Enrollment over Secure Transport and transaction ID

[FabianC]

Dear all,

I am working on a EST server that should interact with Fortigate as the EST client.

The standard workflow works fine for both, Simple Enrollment and Simple Re-enrollment.

Those request can return a 202 - pending status, where, according to the RFC, Fortigate behaves as expected: "The client MUST wait at least the specified "retry-after" time before repeating the same request".

My question: in my EST server, I need to identify the retries for a same request. I would thus like to handle a transactionID to be shared between my EST server and Fortigate. But handling of a transactionID is not part of the EST RFC. It can be customized in my implementation of the EST Server, but my question is: does Fortigate handle a transactionID when it receives a 202, and if yes how does it do it ?

To go a little further: I would like to differentiate each renew operation with a new transaction ID. That is, the 'retries' have the same transaction ID, but the next renew of the certificate, when its date expires once again, should have a new transaction ID. Therefore, deriving the transaction ID from the CSR subject seems not a solution.

Any tip or pointer to existing documentation would be greatly appreciated.
Thanks in advance and best regards

Fabian

[Anthony_E]

Hello Fabian,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[FabianC]

Hello Anthony,

Thank you, yes, help is welcome.

In the meanwhile I tried something that doesn't seem to work: I passed a X-Request-ID header [1] from my EST server back to Fortigate, but on the next call from Fortigate the X-Request-ID was not present.

This could have been a workaround, but "X-Request-ID request header is an optional and unofficial HTTP header". As it is unofficial, maybe Fortigate doesn't support it.

In the meanwhile, I will perform other tests

Best regards

Fabian

[1] https://http.dev/x-request-id

[Anthony_E]

Thank you for sharing this solution! It will help for sure.

[FabianC]

Dear Anthony,

Well, I did not find a solution yet, and any help is still welcome.

The X-Request-ID header I talk about here above, as explained, doesn't seem to work.

If an elegant solution exists, any pointer is appreciated.

Otherwise, maybe the only way is to identify a request "only" with the CSR CN value. But this will not allow to differentiate a first enrollment from a renewal (same CN), which is the problem we are trying to solve.

Thanks for any further help.
Fabian

[Anthony_E]

Hi Fabian,

Let's continue to look for an official then. I keep you update if I find something or someone!

Regards,