> How would I be able to view the Signature Hash Algorithm property using Certutil?
Signature and signature hash algorithm are actually the same thing, hash algorithm just doesn't include public key algorithm name.
Your blog has been really help.
How would I be able to view the Signature Hash Algorithm property using Certutil?
Vadims,
First, great article! Thanks for publishing it and responding to many comments and questions. I am little confused about E-Tag and Max-age headers for CRL HTTP locations and would appreciate if you could clear my confusion.
I'm looking to host the CRLs for the offline Root CA and couple Issuing CAs by the same web farm accessible by a single URL (http:/pki.abc.com/pki). You mentioned that max-age header out of the box is set to 1 week and this in most cases should not be changed. When I look at the default IIS 10 settings, I see the cacheControlMaxAge attribute set to 1.00:00:00 (1 day) and cacheControlMode set to NoControl. SetEtag attribute is set to True. Keeping in mind that our offline root CA will published new CRL every 6 months and all Issuing CAs every 7 days, would you recommend changing cacheControlMaxAge to 7.00:0:00 (1 week) and cacheControlMode to Max-Age? In my opinion, this would work great for the offline root CA as it would force the clients to pull new CRL (if changed) every week. For the Issuing CA CRLs on the other hand, if we were to publish new CRL out of band, the clients would not get the new CRL until the 7 days dicated by the max-age header expire. Is that true statement?
Would it make sense to have one path /pki for issuing CAs CRLs and let's say /rootpki for the offline Root CA CRL? That way you could have different max-age settings for root CA and Issuing CAs.
Thanks again for all you do!
Patrick
> Do you include the '.' because of some bad implementations not following the RFC or was there a newer one that redefined it?
In my opinion, this was overlooked in RFC: RFC explicitly permits wildcards for all name types, but not for dnsName? Although leading period syntax is not explicitly permitted by RFC, it is not prohibited, so this is up to implementer interpretation. And implementer reasoning was somewhat expected: if not explicitly prohibited, the standard could be extended. Reasoning is backed by this statement:
> Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint.
And leading period syntax is required to satisfy this statement, because dot itself is not valid character for DNS label. This syntax was eventually adopted by all major X.509 profile implementations and actually is a de-facto standard. I don't see any issues with it.
Hello,
is there a way to select or specify particular CSP (e.g. Microsoft Enhanced RSA and AES Cryptographic Provider) when creating pfx file?
or is it somehow associated how CSR is generated (e.g. openssl, mmc console or browser api?