Project

General

Profile

Actions

Bug #3956

closed

Check for invalid CA on generating new certificate

Added by Grischa Zengel about 10 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Certificates
Target version:
Start date:
10/24/2014
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

Description

... or check for valid values on generating dynamic function internalca_change() in system_certmanager.php

I had a CA certificate with empty valid-until field.
When I tried to add an new certificate I got all three sections (Import Certificate, Internal Certificate, External Signing Request) at once. Changing method didn't work.

It's not possible to see and understand why you got all three sections and why it's not working, until you debug javaScript.
While generating the function the script errors goes into the function.

I found this broken function:

function internalca_change() {

    index = document.iform.caref.selectedIndex;
    caref = document.iform.caref[index].value;

    switch (caref) {

Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 419
        case "5200d34e2aae4":
            document.iform.dn_country.value = "DE";
            document.iform.dn_state.value = "Hessen";
            document.iform.dn_city.value = "Frankfurt";
            document.iform.dn_organization.value = "RAD-FFM";
            document.iform.dn_email.value = "cert.ffm@dummy";
            break;
        case "544a2eb7e15f1":
            document.iform.dn_country.value = "DE";
            document.iform.dn_state.value = "Hessen";
            document.iform.dn_city.value = "Frankfurt";
            document.iform.dn_organization.value = "Rad-FFM";
            document.iform.dn_email.value = "rad-ffm.pfsense@dummy";
            break;
    }
}
Actions #1

Updated by Jim Pingle about 5 years ago

  • Status changed from New to In Progress
  • Assignee set to Jim Pingle
  • Target version set to 2.5.0
  • Affected Version changed from 2.1.5 to All
  • Affected Architecture All added
  • Affected Architecture deleted ()

Unless we can get a copy of a certificate that shows the behavior, I don't see any problems here. I'm adding some protection against errors, but it isn't foolproof.

Actions #2

Updated by Jim Pingle about 5 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #3

Updated by Grischa Zengel about 5 years ago

Meanwhile this bug doesn't exist like described.

I think I created a CA with pfsense and a high life time (100 years) and got a CA with an empty valid until field.

But it's still possible to get a defect CA if you use 10,000,000 for life time. It's not usual but possible.

Does openssl shows an error while creating and you don't catch it? Or you can check this CA with openssl for validity?

Actions #4

Updated by Jim Pingle about 5 years ago

If you use a lifetime that long, the CA is generated, but nothing can parse it properly (not even OpenSSL at the CLI).

$ openssl x509 -text -noout -in longcaislong.crt 
unable to load certificate
139629642109376:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:../crypto/asn1/asn1_lib.c:101:
139629642109376:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header:../crypto/asn1/tasn_dec.c:1118:
139629642109376:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:190:Type=ASN1_TIME
139629642109376:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:627:Field=notAfter, Type=X509_VAL
139629642109376:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:627:Field=validity, Type=X509_CINF
139629642109376:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:627:Field=cert_info, Type=X509
139629642109376:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:../crypto/pem/pem_oth.c:33:
Actions #5

Updated by Jim Pingle about 5 years ago

  • Status changed from Feedback to In Progress

I tried a few large but more sane values and I'd say around 12000 is probably the highest lifetime we should allow for anything. No real reason to allow more than that (~33 years, minus a bit). That lifetime still works (on amd64 at least). May as well apply that hard upper limit to CA, Cert, and CRL entries.

Actions #6

Updated by Grischa Zengel about 5 years ago

On import you should check the limits too.

Actions #7

Updated by Jim Pingle about 5 years ago

Grischa Zengel wrote:

On import you should check the limits too.

That won't matter. Since the CA fails to parse, it is rejected on import already.

Actions #8

Updated by Jim Pingle about 5 years ago

  • Status changed from In Progress to Feedback

It should be good now with the checks I added earlier today.

Actions #9

Updated by Grischa Zengel about 5 years ago

It looks good.
Thx.

Actions #10

Updated by Jim Pingle almost 5 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF