There are many fields on a certificate revocation list (CRL) like Algorithm, Parameters, Issuer Name, This update date, Next update date, user certificate serial #, etc. While I understand the purpose of most of the fields, of what purpose is the field "next update date" on a certificate revocation List?
See RFC 5280: http://www.ietf.org/rfc/rfc5280.txt
Something similar to the latest date when the next CRL / version of the CRL will be published.
This is the expiry date. Beyond this date this CRL is no longer valid.
It is called "next update" because in normal operations the CRL is supposed to be updated regularly.
Related
I am trying to host a metadata file and act as an IdP.
To generate the metadata I used the following online tool https://www.samltool.com/idp_metadata.php
After filling out the form and building it, the validUntil attribute is set to be the current timestamp.
When trying to test this metadata with https://samltest.id/upload.php it says expired.
When I increment the year and try again the metadata date doesn't seem to change.
How can create an IdP metadata file that is valid?
You can manually change the validUntil value according with your requirement. There won't be any issue during validation on the aforementioned site.
To verify, I just quickly ran through changing the field value and my input meta-data passed the validation.
original
and updated
results.
How would a certificate authority create and maintain a certificate revocation list? When I browse through some CRLs I notice the number of certificates are huge (Eg - http://crl3.digicert.com/ssca-sha2-g6.crl)
Is the CRL maintained/stored as a List<thumbprint, revocationDate> ?
What does a revocation check look like? Is it internally maintained as a HashMap for quicker lookup, but does that scale if the list goes too big?
Here is the specification: https://www.rfc-editor.org/rfc/rfc5280
Depending on the implementation often databases are used internally as source to produce the CRLs.
Is there a particular order in which the subject attributes - C, ST, L, O, OU, CN have to specified. openssl does not seem to enforce an order.
And while generating the Distinguished Name do we pick up all the subject attributes configured in the certificate? Does the ordering of the attributes matter ?
In theory, it doesn't matter but in practice, some crypto libraries are not able to build a chain if the order of tokens in the subject of parent certificate is different than the order of tokens in issuer field in child certificate. They should be exactly the same if you don't want to have any strange issues.
For example, even the windows 10 tool (mmc) doesn't display correctly the chain if the order of tokens in the subject/issuer field is different.
Is there a particular order in which the subject attributes - C, ST, L, O, OU, CN have to specified.
There is no order specified as far as I know. Order that you specify will be used and in this order will DN be generated in i.e. PKCS#10 request.
And while generating the Distinguished Name do we pick up all the subject attributes configured in the certificate?
CA may (and most probably will) use DN from your PKCS#10 request when issuing certificate but it can decide on a different order. Some RDNs (Relative Distinguished Names) can be moved to extensions, i.e. emailAddress or copied to extensions like CN to SubjectAlternativeName when issuing SSL server certificate.
Does the ordering of the attributes matter ?
Ordering does not IMHO matter. It might matter to some application that is consuming the certificate but in general ordering does not matter.
I have an internal Windows Server 2012 Enterprise Root CA and a couple of CDPs. I am trying to ensure a .NET client application running on Windows Server 2012 does not fail when it builds a certificate chain because the CRL and Delta CRL files it uses as part of the process have expired.
So far it seems like a possible solution would be to have overlapping CRLs being issued, to extend the time during which a failure preventing Base CRL publishing can kill an app depending on them (still looking for detailed/non-theoretical explanation on how exactly that is done, if you have examples, please let me know)
Another possible solution (or even in combination with overlapping CAs) would be to have a long CRL publication interval (e.g. 2 weeks) and a short Delta CRL interval (e.g. 1 hour). The question here is - what happens in scenario like this:
A client has cached the Base and Delta CRLs
For one reason or another the Delta CRL cannot be published to the CDPs for, let's say 6 hours - way past the validity of the Delta CRL, but (in most cases) before the Base CRL has expired
After an hour or so (providing the Delta CRL publishes every hour) the last successfully published Delta CRL would have expired, so the only valid one (for some time) would be the Base CRL. Would the client then continue processing since it has cached the Base CRL? Or would it fail? The closest explanation I have found is from this old article: "If a valid base CRL exists and is available, but no delta or time valid delta is available, the certificate chaining engine returns a warning that no delta CRL is available". It seems the client should continue processing and not throw exception and that makes sense, but this is a very old article and I would feel more comfortable with something more up-to-date... :)
So, bottom line, does the above article still hold for modern systems? And if you have any detailed info on how to setup Overlapping CRL publishing on a Windows Server 2012 Enterprise CA, please share... :)
Thanks!
My root certificates are stored as several files in ASN.1 format.
Assume I have a chained end entity certificate in the same format. How do I efficiently determine the root certificate of this certificate?
Currently I have to take a brute force approach which extracts the public key of the end entity certificate and validates that against all root certificates and the first match is considered the root certificate. Is this the right approach??
To find the issuer of a certificate, you should use the "Issuer DN" and match it with the "Subject DN" of the certificates in your CA store. This should reduce significantly the number of signature verification.
It is possible to have different CA certificates with the same "Subject DN" (with different public keys, validity dates, etc.), so your algorithm should be prepared to handle that. The "Subject Key Identifier" and "Authority Key Identifier" can also help to reduce the number of candidates.
Finding the issuing authority is only a small part of the "right approach" to validating certificates. I would advise you to look at part 6 of http://www.ietf.org/rfc/rfc5280.txt "Certification Path Validation". Some parts are most probably overkill (i.e. most things having to do with policies).