Re: [pkix] RFC 5280 and example of a self signed end-entity certificate?

Annie <a.yousar@informatik.hu-berlin.de> Fri, 25 November 2016 07:23 UTC

Return-Path: <a.yousar@informatik.hu-berlin.de>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7241294D1 for <pkix@ietfa.amsl.com>; Thu, 24 Nov 2016 23:23:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.798
X-Spam-Level:
X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=informatik.hu-berlin.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq2bk-2QGOXQ for <pkix@ietfa.amsl.com>; Thu, 24 Nov 2016 23:23:08 -0800 (PST)
Received: from mailout1.informatik.hu-berlin.de (mailout1.informatik.hu-berlin.de [141.20.20.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5E412A14E for <pkix@ietf.org>; Thu, 24 Nov 2016 23:23:05 -0800 (PST)
Received: from mailbox.informatik.hu-berlin.de (mailbox [141.20.20.63]) by mail.informatik.hu-berlin.de (8.14.7/8.14.7/INF-2.0-MA-SOLARIS-2.10-25) with ESMTP id uAP7N1d0017294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <pkix@ietf.org>; Fri, 25 Nov 2016 08:23:02 +0100 (MET)
Received: from [192.168.2.110] (p4FFA5143.dip0.t-ipconnect.de [79.250.81.67]) (authenticated bits=0) by mailbox.informatik.hu-berlin.de (8.14.7/8.14.7/INF-2.0-MA-SOLARIS-2.10-AUTH-26-465-587) with ESMTP id uAP7N0UY017223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <pkix@ietf.org>; Fri, 25 Nov 2016 08:23:01 +0100 (MET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=informatik.hu-berlin.de; s=mailbox; t=1480058581; bh=TheCAtKT6a/YW0c6e+ZsbVSdizRUrGln4Pmo6JrRecM=; h=Subject:To:References:From:Date:In-Reply-To; b=Pa8N3bjKlf1qtrZSf8akO9Sb7g38q4b6kDmAxdHXOmEjn1pFonNO3a8wnOhXVgHpG o6hLfASPmse/V8y/bu+iKtmNdBgSDcSSoD6J9hr1lFe+krkaPhYU/1ZK+x9oYL5hum RjngRHl/GVfE3ma6YhunneZ8Y1gnlg4Kfa5cX2K8=
To: pkix@ietf.org
References: <CAH8yC8m886wq8DOzLcyXgkqQW4vmYCzCdvS78PBtcifMJUEGXA@mail.gmail.com> <1479624960309.7436@cs.auckland.ac.nz> <7BE59266-C79D-42FD-A088-70531D6EB4D4@gmail.com> <CAH8yC8nJSWmEVcbCzeWyO4wzF+jdGQ0Ljht4KnZZ39YoLSnfcQ@mail.gmail.com>
From: Annie <a.yousar@informatik.hu-berlin.de>
Message-ID: <bc3a8f24-6174-7aa0-5b93-b8d8d4a46d7f@informatik.hu-berlin.de>
Date: Fri, 25 Nov 2016 08:23:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <CAH8yC8nJSWmEVcbCzeWyO4wzF+jdGQ0Ljht4KnZZ39YoLSnfcQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at mailbox
X-Virus-Status: Clean
X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.5.1 (mail.informatik.hu-berlin.de [141.20.20.50]); Fri, 25 Nov 2016 08:23:02 +0100 (MET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/MIoNQLL-kEEgaIozfwM2alOAR8I>
Subject: Re: [pkix] RFC 5280 and example of a self signed end-entity certificate?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Nov 2016 07:23:12 -0000

Jeff,
the command
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -nodes

creates not an *EE* certificate but a CA certificate (cA is TRUE).
An EE-certificate has by definition not other certs below, it is a leaf
of the certification path. Therefore in the basicContraints field cA
must be set to FALSE.

E.g.
-----BEGIN CERTIFICATE-----
MIIDWjCCAkKgAwIBAgIJAPJdD4BBetgeMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTYxMTI1MDcxNjA1WhcNMTYxMjI1MDcxNjA1WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxCFKIale9wC6EPQmy4TY2K1NWIqMHnNusRpNtvpDmkKNbnZ/veH3bucr
8/gKtdTsDRJfsT/5m+L3QAOrAHkI6xDYxW0JmhTLrnrfh4sIQtKy7Fkzjl46h92l
M3SoUy6s3SAeV1nF4Aa8bmK+cgWo+NJ7Xegdyt3DHIyVFNWD1G88qZKt8MU8Bskk
16/bpA40GtLVNn+8ALwTjR6F3R0ww8QhtiC+EttQE/lb/bk8LvDJwtU3aUMgrA9g
/LWDAWMB/xPRKNcVDJ0Yuug02zgBvtQhSniw5gGwuBQ+YWONuORpLD6NPMjKr75L
bGAD9nd1HSDI+jcSUIa72Ave9+L3xQIDAQABo00wSzAdBgNVHQ4EFgQU8Yb5SHNN
4H/QSa5RTuy62+NLVbwwHwYDVR0jBBgwFoAU8Yb5SHNN4H/QSa5RTuy62+NLVbww
CQYDVR0TBAIwADANBgkqhkiG9w0BAQsFAAOCAQEACs5ElEzMLJo1XYDBViguS3Is
hg57W4Y/yAPFQPdYSaIays1/2qmKgYDzbD7UK7HszXPmECBpNhxxMMWe2X/pOtj2
fjgd9B7dhUZF7yh56lvQz8SwEC3b2CKHp/HwqHwCVTyFLySoZomP4cr07jIJZL1L
jcIWpITcErCU8xOZeT1cjBSP5oCDx0pW2coo1bt3YGtbLpoJ+AkYtD2SXldNTVsu
rBNHKHpOklwrLwOSuJbTzJ6f0UzNLHHjHXrNzXH8vlhMEZzlEnq1cBGnmjEiKwGT
PyyoH/yPQIvnjxGySjtnpts/b7qvhOlanr+9ItqpgLBLnJ4PRWgarr+WeaTm8g==
-----END CERTIFICATE-----

Check it with the OpenSSL command
openssl verify -CAfile cert.pem cert.pem

Nevertheless I'm not sure that this is correct because the cert is not a
*CAfile*.

Regards,
/Ann.

The SHA-1 issue could be solved easier: add the option -sha256.

Am 24.11.2016 um 23:56 schrieb Jeffrey Walton:
> On Sun, Nov 20, 2016 at 2:06 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>
>> On 20 Nov 2016, at 8:56, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
>>
>> Jeffrey Walton <noloader@gmail.com> writes:
>>
>> Does anyone know where I might find an example of a elf-signed end-entity
>> certificate?
>>
>>
>> By finding an elf and getting them to sign one for you?  Alternatively, if
>> you
>> want a *self*-signed EE cert, by signing one yourself?  Or am I missing
>> something here…
>>
>>
>> I think you’re missing this:
>>
>> openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
>> -nodes
> 
> Forgive m if I am wrong... That creates a malformed server certificate
> because the hostname is placed in the CN and not the SAN, it uses SHA1
> by default, and it fails to use UTF-8 strings by default. At minimum,
> its not following best practices and using deprecated methods.
> 
> I'm also interested in seeing  what an "ideal" or "minimal" client
> certificate should look like. Especially how a principal name, like
> "jdoe" (used as a corporate login), should appear since its probably
> distinct from the Subject DN.
> 
> Jeff
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>