FortiGate Certificate enrollment using SCEP with elliptic curve

[FabianC]

Dear all,
A question about how FortiGate handles the communication with a SCEP server when the CSR is based on elliptic curve.

As stated in this FortiGate article [1], a CSR based on elliptic curve can be sent to a SCEP server.

In that case, and as specified in the SCEP rfc8894 [2]:
"The form of encryption to be applied depends on the capabilities of the recipient's public key. If the key is encryption capable (for example, RSA), then the messageData is encrypted using the recipient's public key with the CMS KeyTransRecipientInfo mechanism. If the key is not encryption capable (for example, DSA or ECDSA), then the messageData is encrypted using the challengePassword with the CMS PasswordRecipientInfo mechanism. "

That further says: "Note that some early implementations of this specification dealt with keys that were not encryption capable by omitting the encryption stage, based on the text in Section 3 that indicated that "the EnvelopedData is omitted"

My question: when emitting a CSR based on elliptic curve, does FortiGate handle the returned value of a certPoll operation properly, using the challengePassword with the CMS PasswordRecipientInfo mechanism ?

Thank you for any answer
Best regards
Fabian

[1] https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiGate-Certificate-enrollment-using-SCE...

[2] https://www.rfc-editor.org/rfc/rfc8894.html

[Atul_S]

Hi Fabian,

It's not easy to explain the steps here that form the basis to justify using EC key type for SCEP and handling of encryption part by means of CMS operation. I will try to explain in a summarised way. In terms of handling of the return value of certPoll operation, it depends upon the the way openssl handles the creation of pkcs7 message since when creating a CSR based on EC, Fortigate specifies the EVP pkey to openssl which in turn uses CMS mechanism to encrypt the message in the certPoll response. I would recommend verify the SCEP enrollment process using EC in a test bed environment to match any standards your organisation has opted for.

Its worth reviewing the below docs as well:

https://datatracker.ietf.org/doc/html/rfc7030

https://docs.fortinet.com/document/fortigate/7.4.0/new-features/317448/support-enrollment-over-secur....

[FabianC]

Hi and thank you very much for your prompt answer.
I will have a look at your pointers, and at how openssl handles this (with -pwri_password).

Maybe the title on my post is a little misleading.
I am working on the development of a SCEP server, and everything was working well with Fortigate when handling RSA CSR.

Now we try to move to a next step to handle elliptic curve CSR.

A very first trial that we did was, from our SCEP server, to return an ECDSA certificate for the GetCACert operation. But then, Fortigate receives the certificate but do not send the csrreq query.

My first question is thus: is it correct that Fortigate do not handle the case when the SCEP server's certificate can not encrypt (ECDSA), that is, Fortigate will not use the challengePassword instead [1].

My second question is about the certPoll, so a further step: if the SCEP server returns a certPoll result encrypte with the challengePassword [1], will Fortigate be able to handle this pkcs7 correctly ?

I will of course go on with tests, but a more formal answer and maybe pointers would be of great help

Thank you and best regards
Fabian

[1] https://datatracker.ietf.org/doc/html/rfc3211

[Atul_S · Accepted solution]

Hi Fabian,

Gday.  For your first question- Yes it is correct, since ECDSA is a signature based algorithm and not encryption based and hence FortiGate expects the SCEP server’s certificate to be able to perform encryption for the challengePassword.

Second- Yes, FortiGate should be able to handle pkcs7 if the SCEP server return a certPoll result encrypted except in a case where an unsupported cipher suit is used.

Thanks,

[Gre9]

Hi Atul,

I do not well understand the final part of your first answer

Gday.  For your first question- Yes it is correct, since ECDSA is a signature based algorithm and not encryption based and hence FortiGate expects the SCEP server’s certificate to be able to perform encryption for the challengePassword.

---

Does that mean that there is no way to use a SCEP server CA certificate with ECDSA keys ? I would have expect that if the server gets an ECDSA certificate from the GetCACert then he will encrypt the pkcs7 certificate request using the challengePassword with the CMS PasswordRecipientInfo mechanism. We did the same test as @FabianC and did not get any request from the Fortigate client.

Thank you very in advance much for your answer !

Best regards,

Greg

[Minkus]

I'm also aiming to enroll an ECDSA certificate on a Fortigate for IPSec VPN - when I run it against Network Device Enrollment Services (NDES - the Windows Server SCEP server), I get the following error:

Couldn't read inner PKCS#7

When I've been troubleshooting other issues, it appears Fortigate may use the open-source SSECP client, which relies on the OpenSSL 'pkcs7' app - and this only supports PKCS7 - and therefore only RSA keys. The 'cms' app also supplied with OpenSSL supports both CMS and PKCS#7 - so if SSCEP is updated to support this, it could all work.

Here are the two relevant bug reports - TL;DR - it may need someone to update SSECP to use CMS, then Fortigate to pull the updated version.

https://github.com/openssl/openssl/issues/24685
https://github.com/certnanny/sscep/issues/183

[FabianC]

Thank you @Minkus for this very helpful comment

[tunipcol1]

Debugging SCEP is hell. There's two(?) commonly implemented drafts, one very recent final RFC (so it can't be assumed as the chosen implementation on any given device), and I very often ended up having to manually decrypt and interpret the asn.1 payloads myself anyway to figure out wtf the pointless breaking detail was.

[karutvo2]

Debugging SCEP is hell. There's two(?) commonly implemented drafts, one very recent final RFC (so it can't be assumed as the chosen implementation on any given device), and I very often ended up having to manually decrypt and interpret the asn.1 payloads myself anyway to figure out wtf the pointless breaking detail was.