Re: [pkix] Self-issued certificates

王文正 <> Fri, 17 July 2015 14:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0B6AC1A0020 for <>; Fri, 17 Jul 2015 07:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.823
X-Spam-Status: No, score=0.823 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_TW=1.335, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yAt5gTEHYMbL for <>; Fri, 17 Jul 2015 07:37:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5CE4E1A001D for <>; Fri, 17 Jul 2015 07:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=bill; c=relaxed/simple; q=dns/txt;; t=1437143875; x=1439735875; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YXfS/KBks+xiiH6Va7lGXY5RzuP0UFZfh3TYKiFfmvE=; b=R2zzQDyHHZ4jIUWSNpnthpVKExC5R7VhHe6IoVzQuHReV4di/ycxRA6NT+pBE3PI pPZCwspQxSgOYNBtoVE2ad6ERSA9RrTiAe/+MT5AFPk92zNeXyi/5T7bzhCrlYQJ /WerYHBzhGC4jC0oWQ49RYnXtshmI5MlVbNSutbXjsA=;
X-AuditID: 0aa00766-f798c6d000002b61-e4-55a9134366fa
Received: from ( []) by (CHT Outgoing ESMTP Mail Server) with SMTP id 6E.D2.11105.34319A55; Fri, 17 Jul 2015 22:37:55 +0800 (CST)
Received: from (unknown []) by (Symantec Mail Security) with ESMTP id D2817C000088; Fri, 17 Jul 2015 22:37:54 +0800 (CST)
Received: from ([fe80::3178:69dd:b794:fa86]) by ([fe80::51e1:3e0d:a18c:1a89%12]) with mapi id 14.02.0342.003; Fri, 17 Jul 2015 22:37:54 +0800
From: =?utf-8?B?546L5paH5q2j?= <>
To: "Miller, Timothy J." <>, "" <>
Thread-Topic: [pkix] Self-issued certificates
Thread-Index: AQHQvO6GAYPrVwbgc064vRlSWTnR1Z3YHn2AgAEqVND//8o1gIABb2ZwgACfJkf//8FjAIABpRXAgABR9cr//4HAgAAo4+OAAAEW84AAAiRdgAABHo0AADyYzOA=
Date: Fri, 17 Jul 2015 14:37:53 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-TW, en-US
Content-Language: zh-TW
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCKsWRmVeSWpSXmKPExsXCtYA9W9dZeGWowZW5/Ba9v3cwW1w8WGQx 7cQ3VgdmjyVLfjJ5vG24yu4x5fNWxgDmqHqbxLy8/JLEklSFlNTiZFul5IwS3ZTM4uScxMzc 1CLd0pI0CyWFzBRbJTMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpecn5KZl26r FBripmuhZPdszpon+xc+2b3taf/6F817n/a0Pp2wOmGNfMbce4tYC5ZIVjzpWcjewHhBoouR nUNCwERinkkXIyeQJSZx4d56ti5GLg4hge2MEh+fTWSGcHYySmy9vI8JwjnMKDHhy35WkBY2 ASOJjWd3MYHYIgLeEkvvnmTpYuTgYBaQkOi7qQASFhbQkbh1Zz9Uia7EpWffwTaICHQxSlzr PQg2h0VAVaKtq4EdxOYV8Jc4eu80mC0kkCfR+XE3mM0pYCtx4NA8sHpGAVmJJwuegQ1lFhCX OHexlR3iBQGJJXvOM0PYohIvH/9jBblHQkBeYtobGYjTNCXW79KH6FSUmNL9EGqroMTJmU9Y JjCKz0IydBZCxywkHbOQdCxgZFnFKFicnJhnaKQHjFS95PxcvZLyTYyQNJK2g3H7fMdDjAIc jEo8vAxXl4cKsSaWFVfmHmKU4GBWEuHdyrUyVIg3JbGyKrUoP76oNCe1+BBjMjBIJjJLiSbn A1NcXkm8obGlsYm5sbmBkaGBIWnCSuK801szQ4QE0oFpLzs1tSC1CGYLEwenVANjKdNO0e93 VefnHp1Rs6u/3fdrscCZ2kV8oonzHCJ4jK6d4ixtNNwd77mwrLjA+MjlAmfPuO/MAbrs1ZO/ HcywKOfa6fn9aOe5JKaNb9MiLhuu0TmosjBbnyX5uSFzfdEB7tPlAc1XnG0q7JPZ0hfLeIdP an8gliK8lueIs0V72Rn7+0xRvUosxRmJhlrMRcWJAJ3V1cJnAwAA
Archived-At: <>
Cc: PKIX <>
Subject: Re: [pkix] Self-issued certificates
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jul 2015 14:37:59 -0000

>> I had not recognized your term "RFC 4210 rollover announcement" as 
>> something that refers to a technical protocol that includes the 
>> relevant PDUs.
>> rfc4210 is sufficient complex and awkward that is not used anywhere 
>> around TLS (at least the stuff that I come in contact with) nor common 
>> web-service or pkcs#7/CMS based data exchange scenarios.
>I didn’t say it was *used*, I said it would *work*.  ;)

Actually, according to my experiences, certification paths with self-issued certificates worked seamlessly in most TLS/SSL environments, except with Microsoft IIS.

In a case where the end-entity certificate is a SSL certificate, after the root key rollover, the certification path will be as follows:

old root self-signed cert --> new-with-old self-issued cert --> subordinate CA cert --> SSL cert

Most SSL/TLS servers, such as apache+openssl, is able to correctly send the certificates payload ("new-with-old self-issued cert --> subordinate CA cert --> SSL cert") to client sides during the SSL/TLS handshake.
Also, most browsers, including IE, Chrome, Firefox, Safari, and Opera, can successfully chain the certification path to the trust anchor (the old root self-signed cert) and successfully validate it because they simply treat the new-with-old self-issued cert as a normal intermediate certificate.

The only problem I had ever encountered is caused by Microsoft IIS. Unlike other SSL/TLS servers which can be configured to send whatever intermediate certificates you specified to the client side, Microsoft IIS insists to automatically decide which are the intermediate certificates for your SSL certificate. Unfortunately, Microsoft IIS incorrectly decides that the new-with-old self-issued cert is not an intermediate certificate to be sent to the client side. My guess is that Microsoft IIS mistakenly treat the self-issued cert as a self-signed root cert (it may thought any cert will be a self-signed cert if the same DN appears in the subject
and issuer fields), therefore it decides not to send it to the client side. The result is a broken certification path in the client side.

Interestingly, Microsoft IE itself can validate the certification path "old root self-signed cert --> new-with-old self-issued cert --> subordinate CA cert --> SSL cert" without any problem.

Wen-Cheng Wang

Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited.  Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.