|
From: Oliver W. <ma...@ol...> - 2025-09-15 17:11:24
|
Hi Mauricio,
you are absolutely right, this change happened by accident. While SCEP
in general will work even with this setup most clients rely on the
issuer certificate being part of the GetCACert response and stumble upon
this. I will review this and fix it with the next update.
best regards
Oliver
On 09.09.25 21:33, Mauricio Silveira via OpenXPKI-users wrote:
> Updating:
>
> I am one of those who hate not knowing what is wrong when something
> doesn't work and won't rest until the core of the issue is revealed...
>
> So I dug deeper, and now I see the "problem": clca will always use
> root certificate to 'certify' any certificate requests ( as intended
> )... and up until version 3.32.7, the scep ra certificate was signed
> by realm issuer CA....
>
> So, this is probably a real fix to get the config working like
> previous versions ( replaced -extension by -name to comply with the
> use of profiles ) :
>
> openssl ca -create_serial -config etc/openssl.cnf -name endentity
> -batch -days 365 -in ratoken.csr -cert issuingca.crt -passin
> env:PASSPHRASE -keyfile issuingca.key -out newcert.pem
>
>
> Was this change intentional? ( I guess not )
>
>
> On 08/09/2025 21:15, Mauricio Silveira via OpenXPKI-users wrote:
>> Hi there.
>>
>>
>> With vanilla docker and 3.32.8 configs, when trying to retrieve scep
>> certs via getcacert ( /usr/libexec/strongswan/pki --scepca --url
>> ${URL} --outform pem --caout certs/CAs/scepca ), the issuer
>> certificate (certs/CAs/scepca-1.pem) is not returned.
>>
>> sscep had the same results, just used ss pki tool to get an obvious
>> verbose command output showing that there's a missing certificate.
>>
>>
>> After *A LOT* of testing with many config combinations, I managed to
>> find the culprit:
>>
>> for some reason, 'clca certify' is breaking the scep ra token....
>>
>> By replacing
>>
>> clca certify --profile endentity --days 365 ratoken.csr
>>
>> with
>>
>> openssl ca -create_serial -config etc/openssl.cnf -extensions
>> endentity_ext -batch -days 365 -in ratoken.csr -cert issuingca.crt
>> -passin env:PASSPHRASE -keyfile issuingca.key -out newcert.pem
>>
>> in sampleconfig.sh, a working certificate is generated.
>>
>>
>> I've made way too many attempts to try to fix this, but I wasn't able
>> to find where to fix ( tried changing/adding profile to openssl.cnf,
>> mixed v.3.32.8 with 3.32.7 configs, etc... )
>>
>>
>> BTW: shouldn't scep tokens include the :scep-ra application suffix to
>> CN?
>>
>> openssl req -new -key ratoken.key -passin pass:secret -out
>> ratoken.csr -subj "/CN=Internal RA" -> -subj "/CN=Internal RA:scep-ra"
>>
>> Another thing I noticed is that, even removing the '--algorithm rsa'
>> for the 'clca genkey' command, getcacert works fine too ( I know,
>> scep doesn't widely support ec algos ( or not al all, not sure about
>> this yet ) ).
>>
>>
>> Any ideas as to why clca is breaking the scep ratoken ?
>>
>>
>>
>>
>> _______________________________________________
>> OpenXPKI-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openxpki-users
>
>
> _______________________________________________
> OpenXPKI-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxpki-users
--
Protect your environment - close windows and adopt a penguin!
|