In issue #503, a request was made to add a -CSRString parameter to New-PACertificate (and New-PAOrder) that would function similarly to -CSRPath but allow the caller to pass a PEM formatted string rather than filesystem path to a PEM formatted file.
Instead of complicating the parameter sets and help for those functions with a new parameter, I decided to try making the existing -CSRPath parameter smart enough to accept a PEM string or a file path. The BouncyCastle PEM parser we're using under the hood requires that the CSR header and footer lines exist on their own line within the string. But it doesn't seem to care about the char width of the inner Base64 lines. So that means both of these would work:
For now, the determination on whether the input parameter is a PEM string or file path is just a fairly simplistic case-sensitive string match on *CERTIFICATE REQUEST*. So there's a potential edge case bug if a user who wants to use a file path names their file something like MY CERTIFICATE REQUEST.csr. But this can also be made more picky if folks start complaining about that.
To keep the overall code churn low, a filesystem copy of the CSR will still be written in the order folder as request.csr even when the CSR is passed in as a string. That should ensure renewal processes run just like they would previously.
In issue #503, a request was made to add a
-CSRString
parameter toNew-PACertificate
(andNew-PAOrder
) that would function similarly to-CSRPath
but allow the caller to pass a PEM formatted string rather than filesystem path to a PEM formatted file.Instead of complicating the parameter sets and help for those functions with a new parameter, I decided to try making the existing
-CSRPath
parameter smart enough to accept a PEM string or a file path. The BouncyCastle PEM parser we're using under the hood requires that the CSR header and footer lines exist on their own line within the string. But it doesn't seem to care about the char width of the inner Base64 lines. So that means both of these would work:But neither of these would work:
For now, the determination on whether the input parameter is a PEM string or file path is just a fairly simplistic case-sensitive string match on
*CERTIFICATE REQUEST*
. So there's a potential edge case bug if a user who wants to use a file path names their file something likeMY CERTIFICATE REQUEST.csr
. But this can also be made more picky if folks start complaining about that.To keep the overall code churn low, a filesystem copy of the CSR will still be written in the order folder as
request.csr
even when the CSR is passed in as a string. That should ensure renewal processes run just like they would previously.