Skip to main content
FabianC
FabianC
New Member
January 23, 2025
Question

Enrollment over Secure Transport and transaction ID

  • January 23, 2025
  • 3 replies
  • 997 views

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

 

 

3 replies

Anthony_E
Staff
Anthony_E
Staff
January 27, 2025

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,

Best Regards
FabianC
FabianCAuthor
New Member
January 27, 2025

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
    Staff
    Anthony_E
    Staff
    January 29, 2025

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

    Best Regards
    FabianC
    FabianCAuthor
    New Member
    January 29, 2025

    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
    Staff
    Anthony_E
    Staff
    January 29, 2025

    Hi Fabian,

     

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

     

    Regards,

    Best Regards
    Terms & ConditionsAccessibility statement