Sorry to hear about the week, I know the feeling, and issues like this are one of the reasons we started offering support contracts, we've already suffered ourselves...
In order to save you further grief down the track I should probably mention there are many profiles out there, and that a certificate without the Authority Key Identifier extension is not in itself invalid. What you are talking about is the issue of creating a certificate for a specific profile and use under that profile - and in that case you need to make sure you understand the expectations of the profile before generating certificates for it as you may also find there are other extensions which are required, and that there may even be extensions specific to the profile you're trying to comply with which don't appear in documents like RFC 5280. I should also point out that RFC 5280 also does allow the extension to be absent under certain circumstances, so simply dismissing a certificate out of hand if it is not present is incorrect as well, and a runtime failure is not appropriate as there may be nothing wrong, even if you're attempting to conform to RFC 5280. With the assertion in CertificationRequestInfo, the structure is invalid if the checked-for fields are empty by definition, quite different from the situation described here. Hope this makes it clearer what is going on. Regards, David On 12/08/15 23:23, Bjartur Thorlacius wrote: > Bouncy Castle developers and prospective developers: > > Using Bouncy Castle C#, I've generated a keypair, and signed the > certificate. Microsoft Windows (Certificat Manager) could not, however, > recognize which in-house certification authority signed the generated > certificate. To find the correct certification authority among the > Trusted Root Certification Authorities, I needed to manually add an > authority key identifier, as documented by Roger Lipscombe: > > var authorityKeyIdentifier = new > AuthorityKeyIdentifierStructure(issuerCertificate); > certificateGenerator.AddExtension( > X509Extensions.AuthorityKeyIdentifier.Id, false, > authorityKeyIdentifier); > > See http://blog.differentpla.net/blog/2013/03/20/bouncy-castle-missing- > certificate-attributes/ > > The authority key identifier is extension is mandated by RFC 5280. > https://tools.ietf.org/html/rfc5280#section-4.2.1.1 > > Considering that the extension field is mandated both by IETF and by a > mainstream implementation, Bouncy Castle should warn if a certificate > is generated without an authority key identifier—or better yet add it > automatically. > > It would have saved me a week of debugging in the dark if either > Windows or Bouncy Castle would have informed me that I was to add an > authority key identifier. In retrospect, the documentation for first > version of the Java BC API does mention how to add an authority key > identifier. But a run-time warning would have been incredibly nice to > have. > > An assertion of similar nature is in > crypto/src/asn1/pkcs/CertificationRequestInfo.cs:62,87. The function > CertificateRequestInfo (and overloads) would be a natural place for > emitting a warning. I don't know how to check if the authority key > identifier has been added, so I can't offer a patch myself. But it > should be a simple if-statement in each of the overloads. > > > In case anyone else stumbled on the same detail, > Bjartur Thorlacius > >
