Project

General

Profile

Actions
Copy link

Bug #11706

closed

Renewing a certificate without a ``type`` value assumes a server certificate

Added by Jim Pingle almost 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
High
Assignee:
Jim Pingle
Category:
Certificates
Target version:
2.5.1
Start date:
03/19/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.5.0
Affected Architecture:

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

Download all 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
Actions
Copy link
 #1

Updated by Jim Pingle almost 4 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #2

Updated by Jim Pingle almost 4 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, 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"
  • 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.
Actions
Copy link
 #3

Updated by Danilo Zrenjanin over 3 years ago

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.

Actions
Copy link
 #4

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 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.

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.

Actions
Copy link
 #5

Updated by Danilo Zrenjanin over 3 years ago

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.

Actions
Copy link
 #6

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.

Actions
Copy link
 #7

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.

Actions
Copy link

Also available in: Atom PDF