I need some information for validating a server certificate.
Am looking to perform date based validation as the first step.
To be precise, am looking at the possibility of expiry of a server certificate that is signed by a CA.
If the CA validity expires on December 2022, can I still get it to sign my server certificate that is supposed to expire only in April 2023?
In other words, if my server certificate has a certain expiry date, can I assume that the CA that signed it also has validity equal to or greater than the server certificate?
If not, should I do a separate date validation for the CA or chain of CAs?
Thanks in advance.
If the CA validity expires on December 2022, can I still get it to sign my server certificate that is supposed to expire only in April 2023?
technically, yes. However most CA implementations restrict issued certificates validity to intersect the CA certificate lifetime.
If not, should I do a separate date validation for the CA or chain of CAs?
as a good practice, you should validate all certificates in the chain. However, I would recommend to NOT write your own validation. Most frameworks provide fully-featured certificate validation engines. Date validation is not the only thing that requires validation, there are many other checks to perform as specified in RFC 5280 ยง6. Use framework-provided APIs to validate the certificate and rely on their results.
Related
I have a scenario in mind where ; When the leaf certificate expires, the intermediate certificate is checked and if the intermediate is not expired, the application will keep running and will not be affected while the leaf is getting updated. Kinda like adding a condition to check the validity of the intermediate certificate in the step of checking the validity of the leaf certificate. Is something like this possible? If so, will there be any security problems with doing this?
If so, will there be any security problems with doing this?
Most CAs won't entertain the notion of revoking an already expired certificate, because it's already the case that no one should be trusting it.
So your scheme, at minimum, reduces the ability to revoke certificates.
The notAfter date in a certificate isn't when the ops people/process should request a new certificate, it's when they need to have already completed the changeover. Making a complicated grace period will just change people who are already not doing it on time to not do it until beyond the grace period... they're clearly error-driven/alert-driven people.
In the beginning of an SSL query, the client sends a CLIENT_HELLO message.
The server replies with a certificate message that gives the chain of verifications going back to a known trusted agent.
Suppose for efficiency I wanted to store certificates locally for a new protocol. The current design in TLS is always to require getting the certificate. What could happen to a certificate that would require me to know?
I am trying to understand possible attack scenarios. Consider doing online banking, and suppose a certificate has been compromised. In such as case, the bank is not criminal, but they have been hacked and have to issue a new certificate. Is this reasonable?
If you consider that the bank itself is corrupt, then it seems to me there is no point in worrying about the certificate since they have your money and can just steal it. If the entity you are dealing with goes criminal, does the certificate matter?
Under what circumstances can certfiicates be revoked? I am trying to understand why SSL sends the certificate each time -- it seems really wasteful, but there is probably a good reason.
Would it be possible instead to keep all certificates stored on the client, but check a timestamp with a trusted server? It seems like one could at least send less data across the network
TLS Certificate message after `ServerHello is mandatory in mostly cases, so caching won't have any useful effect. See RFC5246
7.4.2. Server Certificate
When this message will be sent:
The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the ServerHello message.
TLS has its own methods to improve performance. When client sends a valid session_id in ClientHello the session can be resumed and the parties must proceed directly to the Finished messages
Also RFC5077 specifies how to resume sessions without server-side state
EDITED - added comments to specific questions
Suppose for efficiency I wanted to store certificates locally for a new protocol. The current design in TLS is always to require getting the certificate. What could happen to a certificate that would require me to know?
"always" is not correct. TLS sends certificates during handshake. Once the shared key is negotiated, the session can be resumed later by client using sessionid (the usual behaviour). Then, the server does not send the certification chain.
The server sends the certification chain. The client must verify that the presented certificate is reliable:
checking a digital signature performed with the private key of the server certificat
the certificate is issued by a trusted CA. Is supposed that client has a trust store with the root certificates of the certification authorities it trust. The client builds the certification chain presented by server until it finds the root certificate in local truststore
You can perfectly skip the sending of certificates from the server in the second step step if client has a copy of the server certificate in a local truststore
I am trying to understand possible attack scenarios. Consider doing online banking, and suppose a certificate has been compromised. In such as case, the bank is not criminal, but they have been hacked and have to issue a new certificate. Is this reasonable?
In this scenario the attacker could make a MITM attack. The certificate must be revoked by CA and client should check revocation. This is out of scope of TLS
If you consider that the bank itself is corrupt, then it seems to me there is no point in worrying about the certificate since they have your money and can just steal it. If the entity you are dealing with goes criminal, does the certificate matter?
Seems in this case the certificate is the least of the problems...
Under what circumstances can certfiicates be revoked?
Each CA stablish its own procedure. There is no a standard but there are "good practices": When certificate data changes (e.g email) or becomes invalid (Representative of a company), after a renewal revoke the older one, when key is compromised or certificate is lost
Would it be possible instead to keep all certificates stored on the client, but check a timestamp with a trusted server?
Yes it is possible as commented above: Verify a digital signature, verify revocation and stablish a refreshing mechanism
But if you're looking for performance comparing with TLS, the session resumption will probably have better results
We are required to add certificate for https://www.googleapis.com/youtube/v3/videos to our trusted certificates on our servers for complying with security policies.
We noticed that the certificate expires on the 24th of November,2016. Can someone help with a support team mailing list which we can contact to get the new certificate in advance so that there is no outage for the functionality.
Thanks
I think you are missing a basic concept of TLS: the role of a certificate issuer.
You usually don't lock yourself to a specific certificate for a site and hope that somebody will provide you with the new certificate up front if the old certificate expires and that you then can change all your clients to accept this new certificate. This simply would not scale.
Instead you trust an issuer (CA - certificate agency) to issue a certificate for a specific site. Then you check for any certificate you got that the trust chain to your locally trusted certificate is fine and that the subject of the certificate matches the site you access. The same CA certificate (or at least the public key inside) will be used for many years to issue new certificates, contrary to leaf certificates which are only valid for 1..3 years or even a few month only to reduce the risk of compromise.
In summary: Don't expect anybody to tell you up front when they issue a new certificate because nobody will tell you. Instead do it like everybody else and trust a CA.
TL;DR: you can't. Validate the certificate using CA list.
Google already use a pinning mechanism in chrome:
https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json
But www.googleapi.com is not pinned in that list (only translate.googleapis.com), it means google didn't ensure anything about his keys/certificate/certificate chain. So you can't pin it without taking the risk to break something, even before the renewal: they could change the certificate and/or the chain without notice.
If I set a timestamp with signing, what happens?
What if I don't set?
Is it essential? Why is it recommended?
Timestamping is used to specify time when the digital signature is made. This is needed to properly validate the signature.
If signature timestamp is present, the application which validates (verifies) the signature, will check whether the certificates involved into signature validation were valid at the moment of signing. If there's no timestamp for the signature, certificate validity is checked for the moment of signature validation, which is not always acceptable.
Example:
Certificate is valid from: 1st of January, 2008
Certificate is valid to: 31st of December, 2010
Signature is made on: 4th of July, 2009
Signature is verified on: 30th of April, 2012
With timestamp: signature is ok (signature was made during certificate validity period) Without timestamp: signature is not valid (certificate has expired by the moment of signature verification).
Timestamping should be used if the signature is supposed to be used (to proof authenticity of the document author or data originator) in long term, i.e. longer than one or several days.
Timestamping is not necessary when you, for example, send a short signed note to the colleague and this note is expected to be read and disposed of the same day as it has been written. Of course, timestamping can not be used when it's not supported by the signing technologies or when timestamping authority is not available.
On the other hand, timestamping is a must when you create signed documents for wide distribution or for long-term storage and archiving purposes. Timestamping is also used when signing the executable modules of software applications.
Update: the timestamp is also signed with a certificate. This signature is also validate using regular rules, which means that the certificate used to sign the timestamp must be valid at the moment of signature validation. In the above example if the timestamping certificate expired on the 1st of April, 2012, then the timestamp will be reported as not valid and won't be counted during validation of the signature.
If the signing certificate expires and there's no timestamp, there's no way to verify that the signature was made at a time when the certificate was valid, so previously signed code may just "stop working".
Timestamping involves a third party (usually your CA) attesting that you made the signature at a particular time. Regardless of when your certificate expires, somebody receiving the signed code can then verify that your certificate was valid at the time you signed it.
We have a proprietary framework and now we want to integrate the authentication by client side ssl certificates.
What are the best practices to map a client certificate to a proprietary user account (for example a simple user table in the database)?
Save to public key of the certificate?
Save issuer and serialnumber?
Or are there other possibilities?
Are you issuing the certificates (and have a possibility to set some fields of the certificate)? Does these certificates have to be integrated with a larger scale PKI environment like email-signing (I mean have you the X.509 interoperability nightmare)?
If you can create a certificate authority for the users, and have not to care about foreign systems, you can give each client certificate a common name attribute which maps directly to your user account. So you can check if the client certificate is signed by the user certificate authority and then match the certificate CN attribute.
When there is only a limited and well known number of signing certificates then I recommend to store this certificates and check the client certificates and accept them only if they are signed by one of the signing certificates. Then you use a field of the certificate which the issuing CA sets uniquely for each user (which stays equal when the user certificate gets renewed, many cooperations let user certificates time out after about one year) to connect this field with your user database.
If you can't issue the certificates you can store the hash of the certificate in the database, but this has the drawback that when a certificate runs out of date you need to update the database. The hash is unique to each certificate, while the most fields of a certificate can be spoofed.
You may also want to check the certificate revocation lists for the signing certificate authorities, so no user can access your service with a stolen certificate.
We store the client certificate's serial and issuer DN and match it. According to http://www.tectia.com/manuals/server-admin/60/userauth-cert.html, this is enough to uniquely identify the certificate.