How can you trust the timestamp (and consequently the signature) after its supporting certificate has expired? Isn't it the same as to trust the simple signature after its supporting certificate has expired? And how about RFC 3161 which states:
The TSA signing key MUST be of a sufficient length to allow for a sufficiently long lifetime. Even if this is done, the key will have a finite lifetime. Thus, any token signed by the TSA SHOULD be time-stamped again (if authentic copies of old CRLs are available) or notarized (if they aren't) at a later date to renew the trust that exists in the TSA's signature.
Very insightful article, Vadims! Learnt a big deal. Thank you.
Great work! Thank you!
I am facing an issue in the certificate enrollment from windows 10 client PC's
Usually , when the computer join to domain, the computer automatically gets the certificate from domain.
Now I noticed the certificates are not getting automatically when we join the computer on the domain.
I have manually tried to enroll the certificate using
MMC > Add Snap in > Certificates (Computer Certificates) > Request new certificate
I can see the Active Directory certificate enrollment option in this with proper GUID and when I click next , i am getting the "the certificate types are not available" message window and none of the templates are listed..
When I logged to the same computer with a domain admin account, the enrollment works fine and computer gets the certificate.
I have checked the permission on the templates > domain computers read and enroll and auto enroll permissions are in place.
Is this due to any kerberos issue as I am logging to the computer with local admin user.
Is there any known bug / any other permission issue..
Please advise the fixes if any one experienced similar issue .
© 2008 - 2019 - Sysadmins LV. All rights reserved