Bug #11706
closedRenewing a certificate without a ``type`` value assumes a server certificate
Added by Jim Pingle over 3 years ago. Updated over 3 years ago.
100%
Description
When renewing a certificate, if the type
field is empty, the renewal process results in a certificate with its type set to "server" even if the certificate is not capable of being a server certificate.
It should try to determine the type automatically if possible by checking certificate properties, or leave it empty if it can't be determined.
Files
after_upgrade.png (36.9 KB) after_upgrade.png | Danilo Zrenjanin, 03/27/2021 03:24 AM | ||
after_renewing_user_certificate.png (67.9 KB) after_renewing_user_certificate.png | Danilo Zrenjanin, 03/27/2021 03:24 AM | ||
before_the_recommended_steps.png (77.9 KB) before_the_recommended_steps.png | Danilo Zrenjanin, 04/03/2021 11:49 AM | ||
after_the_steps.png (72.3 KB) after_the_steps.png | Danilo Zrenjanin, 04/03/2021 11:49 AM |
Updated by Jim Pingle over 3 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 009a3d4e16d2905e01fbc0a7b6f53985af3afd09.
Updated by Jim Pingle over 3 years ago
To test:
- On a system without the fix, create test certificates:
- A user certificate with default settings (set the name and CN, leave the rest blank/default)
- A server certificate with the name/CN set but set to Server Certificate, and with a long lifetime (e.g. 3650 days)
- Edit config.xml and remove the
<type>user</type>
from the user certificate created above, andrm /tmp/config.cache
after. - Renew the user certificate, then inspect the resulting certificate details. Note that the list now shows "Server Certificate" for this user entry but also "Server: No"
- Renew the server certificate and select the Strict Security option, then inspect the resulting certificate details. Note that the lifetime was not corrected and remains long. A PHP error may also happen when renewing (check the dashboard).
Upgrade to a build including the fix and repeat the test:
- The resulting user certificate should now have "User Certificate" in the list after renewal, and config.xml should have
<type>user</type>
filled back in. - The resulting server certificate should have the correct strict lifetime (398 days), and no produce no errors.
Updated by Danilo Zrenjanin over 3 years ago
- File after_renewing_user_certificate.png after_renewing_user_certificate.png added
- File after_upgrade.png after_upgrade.png added
Tried to replicate on the:
2.5.0-RELEASE (amd64)
built on Tue Feb 16 08:56:29 EST 2021
In my case, after removing <type>user</type> from the user certificate and renewing it, the list now shows "Server Certificate" for this user entry and "Server: YES"
Renewing the server certificate didn't throw any PHP errors, but the lifetime was not corrected and remained long.
After the upgrade to the latest 2.5.1-RC:
The user certificate was still presented as "Server Certificate" and "Server: YES".
The server certificate life time was correct 398 days.
Updated by Jim Pingle over 3 years ago
Danilo Zrenjanin wrote:
Tried to replicate on the:
2.5.0-RELEASE (amd64)
built on Tue Feb 16 08:56:29 EST 2021In my case, after removing <type>user</type> from the user certificate and renewing it, the list now shows "Server Certificate" for this user entry and "Server: YES"
Renewing the server certificate didn't throw any PHP errors, but the lifetime was not corrected and remained long.
After the upgrade to the latest 2.5.1-RC:
The user certificate was still presented as "Server Certificate" and "Server: YES".
The server certificate life time was correct 398 days.
In your screenshot those are all server certificates, not user certificates. They wouldn't have had this problem and wouldn't have had <type>user</type>
. Looks like you picked the wrong option when creating the "user" cert.
Updated by Danilo Zrenjanin over 3 years ago
- File after_the_steps.png after_the_steps.png added
- File before_the_recommended_steps.png before_the_recommended_steps.png added
I've done the test again on 2.5.0-RELEASE. The outcome is the same.
Initially, I created TestUserCert(User Type).
After the steps proposed for replicating the issue:
- Edit config.xml and remove the <type>user</type> from the user certificate created above, and rm /tmp/config.cache after.
- Renew the user certificate, then inspect the resulting certificate details. Note that the list now shows "Server Certificate" for this user entry but also "Server: No"
TestUserCert changed its type to Server. See the attached screenshots.
Updated by Jim Pingle over 3 years ago
Right, on 2.5.0 (or a 2.5.1 snapshot from before this fix), removing <type>user</type>
will result in a server certificate when renewed. But on a snapshot including this fix, it remains a user certificate. I just updated another fresh VM and tested it. I can break it before the fix, but after I can't get it to come out as a Server cert, which is good.
If you can still make it switch from User to Server on a current 2.5.1 or 21.02.2 snapshot I'll need more information about the specific values in the cert or maybe the config.xml snippet for the CA and cert.
Also, to be clear, a certificate you already renewed on a broken build will NOT switch back to a user certificate -- you must start the procedure over when on a fixed build. Make a new user cert and try to renew it after updating.
Updated by Jim Pingle over 3 years ago
- Status changed from Feedback to Closed
Tested again and this is working fine for me here. Can reopen or make a new issue if additional problem scenarios are found.