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
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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,
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
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
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,
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
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.
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.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1633 | |
1063 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.