View Issue Details

IDProjectCategoryView StatusLast Update
0000807Main CAcert Websitecertificate issuingpublic2014-11-06 14:55
Reporterhanno Assigned ToNEOatNHNG  
PriorityhighSeverityminorReproducibilityalways
Status needs review & testingResolutionopen 
Product Version2010 Q1 
Target Version2014 Q1 
Summary0000807: cacert ignores signature algorithm from csr
DescriptionIf I generate a csr with
    Signature Algorithm: sha256WithRSAEncryption

I get a certificate with
    Signature Algorithm: sha1WithRSAEncryption

So cacert.org is actually ignoring this field and it's impossible to generate sha256-signed certificates with cacert.org.
TagsNo tags attached.
Reviewed by
Test Instructions

Relationships

related to 0001237 closedNEOatNHNG Certificates should be issued using sha512WithRSAEncryption for signatures 
related to 0001101 needs workTimoAHummel general rewrite of get info from csr routine in includes/general.php 

Activities

Sourcerer

2010-01-27 00:08

administrator   ~0001556

CAcert issues certificates on it's own policy with the algorithms chosen by CAcert. CAcert accepts certain algorithms for CSRs, but those are not linked and therefore different to which algorithms are used to issue certificates. For example, CAcert does not issue MD5 certificates for MD5 CSRs.
There are unfortunately too many applications out there which do not allow the user to specify any parameters, so I assume that the user cannot control which algorithm the CSR uses, and it would not make much sense to derive the certificate algorithm from the CSR.

Regarding SHA-2, the plan is to offer a SHA-1 / SHA-2 selection in the webinterface for certificate issueing, so that the user can choose which hash function he wants in the certificate.

hanno

2010-01-27 00:29

reporter   ~0001557

Yeah, I was misunderstanding the meaning of the algorithm passed to the csr. You're probably right that it doesn't make sense.

So please understand this as a feature request that users can choose the signature algorithm ;-)

NEOatNHNG

2014-03-12 17:10

administrator   ~0004638

We recently switched to SHA512 but that gives problems with certain GnuTLS versions (unfortunately those are the default on Debian). So we should switch to SHA256 which seems to be supported and allow users to select SHA512 if they want.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740160 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921

NEOatNHNG

2014-03-20 04:16

administrator   ~0004660

I have implemented a fix and it's available on the test server. Please test and do a second review.

BenBE

2014-03-20 09:23

updater   ~0004661

First impression while doing the second review:
- Shouldn't we do a dropdown box there instead of a list of checkboxes?
- The descriptive text for SHA256 isn't separated properly from the algorithm name IMHO. Using a BR or at least a hyphen to separate should be better.
- The algorithm list and the readable texts are stored duplicated. I'd suggest having a getAlgorithmInfo function returning an array like

return array(
    'sha256' => array('name' => 'SHA-256', 'note' => 'Fallback for software that does not support stronger algorithms (like GnuTLS before 3.x)'),
    'sha384' => array('name' => 'SHA-384', 'note' => ''),
    'sha512' => array('name' => 'SHA-512', 'note' => 'Recommended for maximum protection against hash collission attacks')
    );
And have all other functions read from this array.

- Creating the HTML for this selection field in the form can be centralized into the hash class IMHO.

- Please avoid curly brackets and the closing PHP block indicator on one line. It takes more space but is more readable as it allows the curly brackets to be properly indented and have them be seen more easily.

On first sight the patch looks okay, but the issues mentioned above should get some more discusson.

NEOatNHNG

2014-03-20 14:50

administrator   ~0004662

- Dropdown: only suited for many short strings. Otherwise we would need another way to display the "Note"
- Separation from algorithm name: OK, but I think a br is too strong, looses the connection between value and description
- Dupplication: was done because PHP sucks, and doesn't allow for having localised strings in static variables so one would have to always produce a new array() in a getter like in the display_strings() method. I estimated that keeping the duplicates was not that bad because all changes to that data is encapsulated in a rather small class. Although you're probably right because the getter doesn't get called that often.
- Central HTML: no please keep views and data separated.
- Closing PHP block: don't know what you mean by not being able to indent the braces because of the closing PHP block but if you want to I can do that.

NEOatNHNG

2014-03-20 16:24

administrator   ~0004663

Added a fix for the mentioned issues.

BenBE

2014-03-21 00:49

updater   ~0004665

With the latest changes the patch looks OK and now only lacks some willing testers to verify it works as intended:

- Select the hash algorithm of your choice
- Submit a CSR or SPKAC
- Verify the certificate signature you receive matches the option you have choosen.

dops

2014-03-25 23:06

reporter   ~0004683

Tested on the test system:
SHA-256 leads to SHA-256 signature
SHA-384 leads to SHA-512 signature
SHA-512 leads to SHA-512 signature
Tested with both, class1 and class3, certificates, and verified.
Tested with CSR and without (server created key)

Result: ok

NEOatNHNG

2014-04-15 19:59

administrator   ~0004717

Need to implement renewal

INOPIAE

2014-04-15 20:26

updater   ~0004718

A Client Class 3 certificate sha-384 shows a sha-512 signing algorythm.

Eva

2014-06-11 19:21

updater   ~0004823

Last edited: 2014-06-11 21:41

View 2 revisions

test with class1 and class3 changing:
client cert:
created 2048RSA, sha-265
-> ok
created 2048RSA, sha-384
-> sha-512 -> as mentioned formerly -> ok
created 2048RSA, sha-512
-> ok

org client cert:
created 2048RSA, sha-265
-> ok
created 2048RSA, sha-384
-> sha-512 -> as mentioned formerly -> ok
created 2048RSA, sha-512
-> ok

server cert:
created 2048RSA, sha-265
-> ok
created 2048RSA, sha-384
-> sha-512 -> as mentioned formerly -> ok
created 2048RSA, sha-512
-> ok

org server cert:
created 2048RSA, sha-265
-> ok
created 2048RSA, sha-384
-> sha-512 -> as mentioned formerly -> ok
created 2048RSA, sha-512
-> ok

=> ok (beside of 384 -> 512)

felixd

2014-06-12 22:19

updater   ~0004824

Implementation for digest-copy while renewing a certificate.

https://github.com/yellowant/cacert-devel/tree/bug-807

BenBE

2014-06-13 08:02

updater   ~0004825

An intermediate patch based on commit 57ba86ff84eb3dcc15f8122b29efeae54434652e by Michael Tänzer (NEOatNHNG) has been sent to critical to be applied on the live system. This patch DOES NOT handle renew yet, BUT allows algorithm selection for NEW certificates.

Known issues:
* SHA-384 will be issued as SHA-512 due to a missing whitelisted value in the database. As SHA-384 is a shortened version of SHA-512 this does not reduce hash security.

wytze

2014-06-13 16:09

developer   ~0004826

The intermediate patch for this problem has been installed on the production server on June 13, 2014. See also:
https://lists.cacert.org/wws/arc/cacert-systemlog/2014-06/msg00010.html

BenBE

2014-06-15 16:30

updater   ~0004840

Pulled in further changes to the testserver.

Please verify that renewal of existing certificates is consistent in regards to existing information of the old certificate (e.g. CN, SANs, O, OU - for OrgCerts).

Eva

2014-06-17 21:45

updater   ~0004851

renewed client / server / org client / org server certificates that were originally created with
- sha 256
- sha 384
- sha 512
(with the result of above test)

All sha 256 certificates were renewed signed with sha 256.
All sha 384 certificates were renewed signed with sha 256 - even as the original certificate was signed with 512!
All sha 512 certificates were renewed signed with sha 512.

I'm not sure if the behavior of signing "sha 384" certificates is the intended behavior even as I understand why it is currently doing, what it does.

=> ok for 265 and 512 - not ok for 364

(Minor detail: the menue closes inconsistently with the renew)

BenBE

2014-06-17 21:50

updater   ~0004852

Last edited: 2014-06-17 22:02

View 2 revisions

Due to the way MySQL handles insertion of unknown values of the enumeration the following behaviour can be observed:

Create SHA-384 -> SHA-512 (DB default)
Renew SHA-384 (DB is empty) -> SHA-256 (Software Default)

To solve this issue the following updates need to be executed:

1. Structural update to allow SHA384 (by Critical):
---
ALTER TABLE `domaincerts`
    CHANGE COLUMN `md`
    `md` enum('md5','sha1','sha256','sha512','sha384') NOT NULL DEFAULT 'sha512';
ALTER TABLE `emailcerts`
    CHANGE COLUMN `md`
    `md` enum('md5','sha1','sha256','sha512','sha384') NOT NULL DEFAULT 'sha512';
ALTER TABLE `orgdomaincerts`
    CHANGE COLUMN `md`
    `md` enum('md5','sha1','sha256','sha512','sha384') NOT NULL DEFAULT 'sha512';
ALTER TABLE `orgemailcerts`
    CHANGE COLUMN `md`
    `md` enum('md5','sha1','sha256','sha512','sha384') NOT NULL DEFAULT 'sha512';
---

2. Fixup all SHA-384 certificates to match behaviour and actually issued Hash:
---
UPDATE `domaincerts` SET `md` = 'sha512' WHERE `md` = '' AND `created` > '2014-06-01 00:00:00';
UPDATE `emailcerts` SET `md` = 'sha512' WHERE `md` = '' AND `created` > '2014-06-01 00:00:00';
UPDATE `orgdomaincerts` SET `md` = 'sha512' WHERE `md` = '' AND `created` > '2014-06-01 00:00:00';
UPDATE `orgemailcerts` SET `md` = 'sha512' WHERE `md` = '' AND `created` > '2014-06-01 00:00:00';
---
Rationale: Only entries created after the intermediate patch went online legitimately show this behaviour. Critical should review the result of the following query to be 0 for all rows:
---
SELECT 'domain', COUNT(*) FROM `domaincerts` WHERE `md` = ''
UNION
SELECT 'email', COUNT(*) FROM `emailcerts` WHERE `md` = ''
UNION
SELECT 'orgdomain', COUNT(*) FROM `orgdomaincerts` WHERE `md` = ''
UNION
SELECT 'orgemail', COUNT(*) FROM `orgemailcerts` WHERE `md` = '';
---

If any of the resulting rows of the previous statement is non-zero a dispute should immediately be filed to handle the cleanup.

Eva

2014-06-17 22:08

updater   ~0004855

I'm not sure if 2. is covered with the authority of software or critical, especially as it changes DB-entries for our certificates.

I would propose to enter a dispute for this by arbitration.

INOPIAE

2014-11-06 14:55

updater   ~0005092

I filed a dsiput about the sql update statements today.

Issue History

Date Modified Username Field Change
2010-01-26 15:42 hanno New Issue
2010-01-27 00:08 Sourcerer Note Added: 0001556
2010-01-27 00:29 hanno Note Added: 0001557
2010-07-29 16:02 Sourcerer Priority normal => low
2013-01-07 21:59 Werner Dworak Relationship added related to 0001101
2014-03-12 17:05 NEOatNHNG Assigned To => NEOatNHNG
2014-03-12 17:10 NEOatNHNG Note Added: 0004638
2014-03-12 17:10 NEOatNHNG Status new => needs work
2014-03-12 17:11 NEOatNHNG Relationship added related to 0001237
2014-03-18 23:30 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable cf35d7da
2014-03-18 23:30 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 1c5409b0
2014-03-18 23:30 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 2d5c9ce4
2014-03-19 00:25 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable fb601223
2014-03-19 00:25 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable f90c5f99
2014-03-19 00:25 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 23355713
2014-03-19 00:30 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 60729146
2014-03-19 00:30 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 49dfffa3
2014-03-19 23:45 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 0677a40c
2014-03-19 23:45 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 8df925a3
2014-03-19 23:45 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 1d08addf
2014-03-19 23:45 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 50d8cd64
2014-03-19 23:45 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable dab06a96
2014-03-20 03:30 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable ff488eeb
2014-03-20 03:30 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 8872049b
2014-03-20 03:50 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 4c893dbf
2014-03-20 03:50 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable b5b461e1
2014-03-20 04:15 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable dd0ff930
2014-03-20 04:15 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 1a9707d9
2014-03-20 04:16 NEOatNHNG Reviewed by => NEOatNHNG
2014-03-20 04:16 NEOatNHNG Note Added: 0004660
2014-03-20 04:16 NEOatNHNG Assigned To NEOatNHNG => BenBE
2014-03-20 04:16 NEOatNHNG Priority low => high
2014-03-20 04:16 NEOatNHNG Status needs work => needs review & testing
2014-03-20 04:16 NEOatNHNG Target Version => 2014 Q1
2014-03-20 09:23 BenBE Note Added: 0004661
2014-03-20 14:50 NEOatNHNG Note Added: 0004662
2014-03-20 16:24 NEOatNHNG Note Added: 0004663
2014-03-20 16:25 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 47620272
2014-03-20 16:25 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 9183b445
2014-03-21 00:15 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable d9f88e53
2014-03-21 00:15 NEOatNHNG Source_changeset_attached => cacert-devel testserver-stable 57ba86ff
2014-03-21 00:49 BenBE Reviewed by NEOatNHNG => NEOatNHNG, BenBE
2014-03-21 00:49 BenBE Note Added: 0004665
2014-03-21 00:49 BenBE Status needs review & testing => needs testing
2014-03-21 00:49 BenBE Product Version => 2010 Q1
2014-03-25 23:06 dops Note Added: 0004683
2014-04-15 19:59 NEOatNHNG Note Added: 0004717
2014-04-15 19:59 NEOatNHNG Assigned To BenBE => NEOatNHNG
2014-04-15 19:59 NEOatNHNG Status needs testing => needs work
2014-04-15 20:26 INOPIAE Note Added: 0004718
2014-06-11 19:21 Eva Note Added: 0004823
2014-06-11 21:41 Eva Note Edited: 0004823 View Revisions
2014-06-12 22:19 felixd Note Added: 0004824
2014-06-13 08:02 BenBE Note Added: 0004825
2014-06-13 08:05 BenBE Source_changeset_attached => cacert-devel release 6d0f4148
2014-06-13 08:05 BenBE Source_changeset_attached => cacert-devel release f25f8af0
2014-06-13 08:05 BenBE Source_changeset_attached => cacert-devel testserver-stable 78742777
2014-06-13 16:09 wytze Note Added: 0004826
2014-06-15 16:25 BenBE Source_changeset_attached => cacert-devel testserver-stable 7efed7ae
2014-06-15 16:25 BenBE Source_changeset_attached => cacert-devel testserver-stable 53c84b22
2014-06-15 16:25 felixd Source_changeset_attached => cacert-devel testserver-stable b463d175
2014-06-15 16:30 BenBE Reviewed by NEOatNHNG, BenBE =>
2014-06-15 16:30 BenBE Note Added: 0004840
2014-06-15 16:30 BenBE Status needs work => needs review & testing
2014-06-17 21:45 Eva Note Added: 0004851
2014-06-17 21:50 BenBE Note Added: 0004852
2014-06-17 22:02 BenBE Note Edited: 0004852 View Revisions
2014-06-17 22:08 Eva Note Added: 0004855
2014-11-06 14:55 INOPIAE Note Added: 0005092