On Saturday, December 10, 2016 at 3:30:09 AM UTC+2, Erwann Abalea wrote: > I don't think there is a bug in IIS here. IIRC, you discovered that IIS > doesn't send the self-issued certificate when loaded with the 2 self-signed > root certs and the self-issued cert (1st gen signing 2nd gen). And IIS' > behaviour is right, in that it doesn't know if the browser will need this > link certificate. IIRC again, what was proposed for you is that you declare > the 2nd gen self-signed cert as untrusted on your side, to force IIS to send > the link. >
Well, regarding whether it is a bug, I think that depends on whether IIS can distinguish self-issued certificates from self-issued certificates? In our speculation, we guess that IIS treats any certificate of which issuer DN and subject DN are the same as a self-issued certificate. That is why we submit a bug report to Microsoft to explain to them that it might be a self-issued certificate according to RFC 5280 and the X.509 standards. We guess the reason why IIS will not send back our self-issued intermediate certificate to the client is that it treat it as a self-signed root certificate (Note that in SSL/TLS protocol, the server side does not need to send back self-signed root certificates to the client side.) However, if IIS development team does know the different between a self-issued certificate and a self-signed certificate, and they decide not to support self-issued certificates for some reason. Well, you can say that it is not a bug and it is by design. > Talking about your duties when playing with such renewals, you already know > that the population under GCA 1st gen and GCA 2nd gen is the same with regard > to generated serial numbers and CRLs produced (the content of the CRL > chaining to GCA 1st gen MUST be identical to the content of the CRL chaining > to GCA 2nd gen, unless you implement CRL partitioning). > In our National LDAP Tree, GRCA and GCA are both permanent entities. After they performing re-key, they are still the same entities in the National LDAP Tree but with different generations of keys. The same situations also apply to re-keys of end-entities. When end-entities' key expired, they will simply generate new keys and apply for new certificate with the same DNs. Please be understood that we have a National LDAP Tree and we intend to keep all entities' DNs permanent, unless they really change their names of jurisdictions. > And the situation gets weirder with the Root. In X.509, GDCA 1st gen and GDCA > 2nd gen are a single CA (serial numbers assigned to issued certs, CRLs, etc). > And there's a difference here between RFC5280 and X.509. In RFC5280, the CRL > chaining to GDCA 1st gen can't give a valid revocation result for a > certificate chaining to GDCA 2nd gen, and thus the set of serial numbers for > certs issued by each gen of GDCA may or may not be disjoint. It's an unclear > area of RFC5280, and it's not fun to sit in here. > > >From what I see, you're doing it correctly from an X.509 point of view. Each > >GCA gen produces its partitioned CRL plus an unpartitioned complete one, > >both complete ones are identical in content (except a few seconds delta in > >the thisUpdate field, unimportant). And I found 3 CRLs issued under GDCA, > >with identical contents. That should also work if RFC5280 rules are followed. > You are right, RFC 5280 is unclear about the relationship between two generations of CRLs. In this matter, we indeed follow what the original X.509 standards says. That is each CA should still issue the Complete CRL even if they issue partitioned CRL. > Mozilla::pkix doesn't know about self-issued certificates. The library just > considers such a certificate as a subordinate CA cert. It happens to work in > your specific situation. > > > Other https server such aa Apache have no problem with certificate chains > > containing self-issued certificates. > > That may not be true in recent versions, depending on how you configure your > server. But again, off-topic. Yes, actually I think those browsers and https server doesn't know about self-issued certificates, they simply treat them as intermediate CA certificates. However, you know, the original idea of using self-issued certificates to facilitate key-rollover is actually want certificate-using systems treat them like intermediate CA certificates. Wen-Cheng Wang _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
