Re: Multi-level certificate chains
You can add a caIssuer entry to the authorisInformationAccesss extension of cert B and C. Put an URL where you can download the issuing certificate (so cert C has a URL to download cert B). That way, windows can automatically fetch the intermediate certificate. cheers Mat On Tuesday 12. November 2013 17:47:54 you wrote: Hi there!I am trying to create my own CA, but am having some small issues:I can create the root CA, then an intermediate CA, both of these are linked correctly in the certification path ie. it shows that Cert B was signed by Cert A, but when I sign a certificate with the IA (Cert B) the signed certificate (Cert C) has no certification path and has a warning that windows couldn't verify the certificate's origin. Is there a way I can make all three linked? ie. Cert A-Cert B-Cert C in the certification path? Any help would be appreciated signature.asc Description: This is a digitally signed message part.
OpenSSL doesn't treat RFC 3280 validations as an error?
Hi, please see the following certificate: -BEGIN CERTIFICATE- MIIEbTCCA1WgAwIBAgICLgAwDQYJKoZIhvcNAQEFBQAwQDELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDkdlb1RydXN0LCBJbmMuMRgwFgYDVQQDEw9HZW9UcnVzdCBTU0wg Q0EwHhcNMTAxMDE5MDQyMDUwWhcNMTUxMDIwMjMzNTI0WjCBhDEpMCcGA1UEBRMg bnFxRThGb0stQmpPbk9POTBWTE1mM3BBZnYyLUpNaHYxCzAJBgNVBAYTAkRFMQkw BwYDVQQIEwAxEjAQBgNVBAcTCUthcmxzcnVoZTEUMBIGA1UEChMLbmV0Y3VwIEdt YkgxFTATBgNVBAMMDCoubmV0Y3VwLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALGrLGsBDRViP5QEvcNeVXMBMm8F0AmukbxO+OFmvA6E54lCwAn7 ehdJc3ix/+KTKTAuOl33YmB51FUvUFWlf1MwwFRlIsR/oftPM2gthc1+T/IuzhV9 9kP8qM56R5vzivOK7nIh5ZeYbdInhgxOshoADdVHWc8uRefSygcoGOZqAISl6xfd NRNsaGtZ3mIApG4vxbbx/ZOMKKCEeLW5PlDE0YoGTtjHtPhggi85Z44ibT/SaURz 4z+lrnsjnyN8+8UgL3lrjnXDdsgxoDNB0dyqSQkBX3g2uRhfwXG9v+K7bUhkTZba ba9XQZcnrO7xo5gy15xYAKA3+lBJAR58FtUCAwEAAaOCASowggEmMB8GA1UdIwQY MBaAFEJ5VBthzVUrPmPVPEhX9Z/7Rc5KMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwIwYDVR0RBBwwGoIMKi5uZXRjdXAubmV0 ggpuZXRjdXAubmV0MD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly9ndHNzbC1jcmwu Z2VvdHJ1c3QuY29tL2NybHMvZ3Rzc2wuY3JsMB0GA1UdDgQWBBSx2qZZO5XjEM7Y PQzRrKKAZE7FtzAMBgNVHRMBAf8EAjAAMEMGCCsGAQUFBwEBBDcwNTAzBggrBgEF BQcwAoYnaHR0cDovL2d0c3NsLWFpYS5nZW90cnVzdC5jb20vZ3Rzc2wuY3J0MA0G CSqGSIb3DQEBBQUAA4IBAQA//wCMkJ9sBtQ4PYoLcvkjrZcvj5o2J5nSIbuOlvbH alJN5pQye9rpuwlrVHKP2V19Y3zL+rRvrXXQ4f3XHskh/xiNpliqFgVCxV0ikF53 xlXkUlC175vRgksv3CgyIIqnZ9tBfF7OBd5mOSYon2fQjv5RKL+aXXTYZqkO+FMq AKUt0nsF2vQDRC+AEZJj08tKaAwAVjCGYtn3lh8DpazXWZEUbfW4g2kz4dQMgWYt 9AxmgV724ImDdhcNuBl7pi8IrUuRh+3JMTZ5f2mOqCMBEAD7C7HC7g7qxr4DuTeo uKnvqzQP10A7f3PBsGYRA2DCeMDavaEoizJnNyjCOQx4 -END CERTIFICATE- It seems to be a valid certificate for OpenSSL, right? But it isn't, see the OID 2.5.4.8 (stateOrProvinceName): 0b0: 310b 3009 0603 5504 0613 0244 4531 0930 1.0...UDE1.0 0c0: 0706 0355 0408 1300 3112 3010 0603 5504 ...U1.0...U. 0d0: 0713 094b 6172 6c73 7275 6865 3114 3012 ...Karlsruhe1.0. Octal sequence 3109300706035504081300.. The value has zero length. According to RFC 3280, which defines X.509 certficates, these entries, if they exist, must not have an empty value. Am I wrong? I found this problem while using FileZilla (which uses GnuTLS), which denied to connect to a host using such a (broken) certificate: Error: GnuTLS error -71 in gnutls_x509_crt_get_dn: ASN1 parser: Generic parsing error. Error: Could not get distinguished name of certificate subject, gnutls_x509_get_dn failed Error: Could not connect to server For further details please see: https://forum.filezilla-project.org/viewtopic.php?f=2t=31046 I am wondering why OpenSSL doesn't complain. Tested with OpenSSL 1.0.1e 11 Feb 2013. Please tell me what you think: - Am I wrong? - Isn't that a bug? - Is GnuTLS wrong? - Did I misunderstood RFC 3280? Thanks! -- Regards, Igor
Re: [openssl-users] OpenSSL doesn't treat RFC 3280 validations as an error?
Bonjour, Le 13/11/2013 11:35, Igor Sverkos a écrit : Hi, please see the following certificate: -BEGIN CERTIFICATE- MIIEbTCCA1WgAwIBAgICLgAwDQYJKoZIhvcNAQEFBQAwQDELMAkGA1UEBhMCVVMx [...] uKnvqzQP10A7f3PBsGYRA2DCeMDavaEoizJnNyjCOQx4 -END CERTIFICATE- It seems to be a valid certificate for OpenSSL, right? OpenSSL can parse it, yes. But it isn't, see the OID 2.5.4.8 (stateOrProvinceName): 0b0: 310b 3009 0603 5504 0613 0244 4531 0930 1.0...UDE1.0 0c0: 0706 0355 0408 1300 3112 3010 0603 5504 ...U1.0...U. 0d0: 0713 094b 6172 6c73 7275 6865 3114 3012 ...Karlsruhe1.0. Octal sequence 3109300706035504081300.. The value has zero length. According to RFC 3280, which defines X.509 certficates, these entries, if they exist, must not have an empty value. RFC5280 doesn't define X.509 certificates, it defines a profile of X.509 certificates. X.509 defines X.509 certificates. Reading X.520 shows that the DirectoryString type disallows 0-sized elements. So you're right, this isn't a valid X.509 certificate. I found this problem while using FileZilla (which uses GnuTLS), which denied to connect to a host using such a (broken) certificate: Error: GnuTLS error -71 in gnutls_x509_crt_get_dn: ASN1 parser: Generic parsing error. Error: Could not get distinguished name of certificate subject, gnutls_x509_get_dn failed Error: Could not connect to server Following gnutls code is hard, but I think I tracked down to the faulty function. String objects are decoded as OCTETSTRING ones, and the ASN.1/DER parser can't parse OCTETSTRING objects whose length is = 0. The error returned is ASN1_GENERIC_ERROR. For further details please see: https://forum.filezilla-project.org/viewtopic.php?f=2t=31046 I am wondering why OpenSSL doesn't complain. Because it has a more tolerant parser. GNUtls is primitive in some aspects, DN parsing is one of them. Anyway, the fault is shared between GNUtls and the CA. Not with OpenSSL.
Re: [openssl-users] OpenSSL doesn't treat RFC 3280 validations as an error?
Hello, thank you for your response. There's one thing in your reply I don't understand: Erwann Abalea wrote: It seems to be a valid certificate for OpenSSL, right? OpenSSL can parse it, yes. [...] Reading X.520 shows that the DirectoryString type disallows 0-sized elements. So you're right, this isn't a valid X.509 certificate. [...] GNUtls is primitive in some aspects, DN parsing is one of them. Anyway, the fault is shared between GNUtls and the CA. Not with OpenSSL. If it isn't a valid X.509 certificate as you agreed, shouldn't openssl complain when I verify/establish a connection using AUTH TLS which will use this certificate? So for me it is not a question about tolerance like you said OpenSSL's ASN1 parser is more tolerant than GnuTLS (it uses libtasn1 BTW): If the certificate is invalid, OpenSSL should tell it and verify shouldn't pass. Not? -- Regards, Igor
Re: OpenSSL doesn't treat RFC 3280 validations as an error?
On 13 November 2013 10:35, Igor Sverkos igor.sver...@googlemail.com wrote: According to RFC 3280, which defines X.509 certficates, these entries, if they exist, must not have an empty value. FWIW, RFC 3280 has been obsoleted by RFC 5280. I couldn't find where it said this in RFC 5280. Pointer? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: OpenSSL doesn't treat RFC 3280 validations as an error?
This is taken from X.520/RFC5280:
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) }
Nearly every attribute type is encoded as a DirectoryString. An empty
element doesn't respect the size constraint, so is invalid.
--
Erwann ABALEA
Le 13/11/2013 11:48, Ben Laurie a écrit :
On 13 November 2013 10:35, Igor Sverkos igor.sver...@googlemail.com wrote:
According to RFC 3280, which defines
X.509 certficates, these entries, if they exist, must not have
an empty value.
FWIW, RFC 3280 has been obsoleted by RFC 5280.
I couldn't find where it said this in RFC 5280. Pointer?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] OpenSSL doesn't treat RFC 3280 validations as an error?
Le 13/11/2013 13:30, Igor Sverkos a écrit : Hello, thank you for your response. There's one thing in your reply I don't understand: Erwann Abalea wrote: It seems to be a valid certificate for OpenSSL, right? OpenSSL can parse it, yes. [...] Reading X.520 shows that the DirectoryString type disallows 0-sized elements. So you're right, this isn't a valid X.509 certificate. [...] GNUtls is primitive in some aspects, DN parsing is one of them. Anyway, the fault is shared between GNUtls and the CA. Not with OpenSSL. If it isn't a valid X.509 certificate as you agreed, shouldn't openssl complain when I verify/establish a connection using AUTH TLS which will use this certificate? Well. It could be very strict. Would it solve the problem you have with gnutls? No. Does this tolerance have any security impact? No. So for me it is not a question about tolerance like you said OpenSSL's ASN1 parser is more tolerant than GnuTLS (it uses libtasn1 BTW): If the certificate is invalid, OpenSSL should tell it and verify shouldn't pass. Verifying the presented certificate with certtool from gnutls version 3.0.11 on my Ubuntu 13.10 works (haven't checked if they have special patches for this). Place your certificate+issuingCA+rootCA in a file, and run certtool -e --infile allcerts.pem.
RE: Multi-level certificate chains
From: owner-openssl-users On Behalf Of Walter H. Sent: Tuesday, November 12, 2013 05:08 On Tue, November 12, 2013 05:47, Alan Jakimiuk wrote: Is there a way I can make all three linked? this should be the default. ie. Cert A-Cert B-Cert C in the certification path? Any help would be appreciated can you view the certificates? openssl x509 -noout -text -in certfile you should see in both, the intermediate and the Cert C something like X509v3 Authority Key Identifier: keyid:EB:DF:B2:26:76:... serial:6F:7F:C0:... If certs created with openssl commandline (which OP didn't actually say) you can have both keyid and serial only if the issuance operation specified keyid[:always],issuer:always which the standard openssl.cnf doesn't. And in that case you will have DirName in between. (Or at least should; PKIX allows Subject empty for EE cert but not CA cert, and since it's hard to create *any* Subject empty with openssl I didn't test violating that.) the serial in the intermediate here must match the serial of the root, and of Cert C the one of the intermediate and the DirName in both matches the root (and the intermediate Issuer). But only for a chain of 3, the case asked; for longer chains it is different. Note however this *links* the chain-of-3, as literally asked, but it does not by itself allow *verifying* the chain-of-3, which appears to be what the OP actually wants. And for verifying I don't think you actually need the AKI linkage, although it might depend on Windows version or maybe some setting(s) someplace. What you do need is all three certs available at verification time. For example I can have an SSL server send leaf and intermediate (OP's C and B) to IE on Windows that has only the root (A) in TrustedRoots, and it verifies, and displays the path correctly, with no AKI at all, only the classic Issuer-Subject linkage (which is slightly less work for me to set-up). To OP: Do you want to verify this chain (or your cert C using this chain), and if so specifically what are you doing? Using it in SSL? Using it in SMIME or similar? Just opening the cert by itself in CryptExtBlah? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
