My understanding is that the digital certificate is valid up to 3 years depending upon what you paid for to the certificate issuing company. So for example, If I bought a DSC from say, emudhra, and it is valid for 2 years. If I sign a document on 1/6/2017 and the DSC is valid from 1/1/2017 to 1/1/2019, will the document that I signed only be valid for 1.5 years from 1/6/2017 or will it be valid for the 2 years?
Also once the DSC I have expires on 1/1/2019 if I renew the certificate for another 2 years. Will the documents I signed be valid for a total of 4 years or will I have to sign it again with the renewed DSC for the certificate to be valid?
A certificate can expire, be revoked and the signature could still be valid, so the question should be How do I prove that a signature was valid at the time of signing?
Answering this question is not simple at all. I will try to explain how to verify a (basic) digital signature:
cryptographically valid: message/signature not altered and public and private key correspondence.
certificate not revoked or expired: checked using an online OCSP query to the Certificate Authority or downloading a CRL
certificate chain trusted: the root certificate of the issuing CA present in the client truststore.
There are many additional checks if you use an advanced format like CAdES or XAdES, but these are the basics.
When you need to verify a signature over time you need to keep all evidence of the validation process: certificates, CRLs, OCSP responses and protect them with a time stamp (RFC3161). When the time stamp is about to expire, an additional time stamp is added
Now, I will try to answer your original questions in a concise way
If I sign a document on 1/6/2017 and the DSC is valid from 1/1/2017 to 1/1/2019, will the document that I signed only be valid for 1.5 years from 1/6/2017 or will it be valid for the 2 years?
Validation of the signature will fail after 1/1/2019, or earlier if the certificate is revoked. To avoid this behaviour, store the revokation evidences and use them in the verification process
Also once the DSC I have expires on 1/1/2019 if I renew the certificate for another 2 years. Will the documents I signed be valid for a total of 4 years or will I have to sign it again with the renewed DSC for the certificate to be valid?
The original signature will be considered invalid after 1/1/2019, even if you renew the certificate or add new signature
Related
This question already has answers here:
Expired SSL Certificate and Encryption
(1 answer)
Is an expired X509 certificate on a website a security issue?
(1 answer)
Closed last month.
When you visit a website and it shows (not secure) with a red lock icon, does that mean the data is not being encrypted?
Normally when an SSL certificate is valid two things will happen:
your computer will verify that the website you access is the real one (verification)
the incoming and outgoing data will be encrypted (encryption)
Are they working together or there are some cases when verification fails but encryption still works?
is there a way to check if the encryption is working? and block the access if the encryption is not working?
Yes, the data is still encrypted. The red lock icon is only a warning that the certificate has expired.
I have an SSL certificate that I am using to secure port 443 (HTTPS) on my nginx server running on Ubuntu for about 10 months now.
When I bought the cert, I got it for one year, so I have about 2 more months with this certificate.
My question is: "When I renew this cert, Will I just need to pay for renewal? or will I have to re-issue the cert with a new CSR, and have a potential downtime while installing?
I need to plan for any downtime from now.
Thanks in advance for your answers.
It's not possible to extend the expiration of an existing certificate once issued. The only way is to issue a new certificate.
Most certificate authorities offers a "renewal" concept, which provides some advantages compared to a new purchase. For example, you can renew in advance to the certificate expiration, and they will issue the new certificate from the expiration of the previous one, and not from the day the new one is issued.
The re-issue or re-key is a different thing. It generally means re-keying an existing certificate order with a different private key and/or CSR. It generally doesn't change the expiration of the certificate, hence it's not a renewal. Both renews and rekeys result in a new certificate (again, it's not possible to change an existing certificate once issued), but the rekey only alters the certificate information and not the expiration.
A renewal can be issued with the same original CSR and key, or with a completely new one. It's up to you.
As in all cases a new certificate is issued, you will have to replace the existing one. Replacing a certificate is generally a no-downtime task. You simply upload the new one, change the server settings and reload them (or restart the server).
Most webservers including Nginx supports hot reloads, therefore you don't need to restart the server and wait for it to reboot.
If planned correctly, the renewal will be a no downtime task.
To get the new one you might or might not need to submit a new CSR, depending on the CA. But in any case you get a new certificate file and need to replace the existing certificate on your server with a new one. See also
https://www.digicert.com/ssl-certificate-renewal.htm
Renewal of SSL certificate keeps security on your website alive along with your verified identity. The lapse in renewal can cause a warning on your website and warns your customers to move away from your site.
It depends on the SSL provider that you should continue with old CSR or generate new CSR, but it is recommended to create a new one to get rid of misconfiguration. However, it is a myth that your server will face downtime in the renewal of SSL certificate.
Certificate renewal and re-issuance both are different terms. Certificate renewal happens after the expiry of a certificate, while certificate re-issuance in the case of lost of a private key, want to change the domain/organization name or add new SAN names.
Most certificate providers are sending renewal reminder email frequently before certificate expiry. So, It is advisable to renew your certificate earlier, you can take advantage of getting additional validity period from early renewals.
This article may help you to understand the certificate renewal process. https://www.ssl2buy.com/wiki/how-to-renew-ssl-certificate/
Shortly to answer, no renewing SSL Certificate does not require re-issuing the cert, simply because reissue and renewal are 2 different actions with SSL certificate.
As you explained your situation, you are left with 2 months with your existing certificate and after that it will expire, so a Renewal is required. A Reissue (Revoke & Replace) is quite different, in that you cancel your current, valid SSL/TLS Certificate due to any of the reason and request for a new one.
Reissue:
Reissue of Certificates is the process where certificate has to be regenerated with Certificate Authority if needed. For example, if you have lost your Private Key. For that CA views the details of your certificate from list of certificates they have and then reissue the Certificate.
Furthermore, the process is quite same like in similar way activation will take place, like pasting of CSR for same domain name, selecting & approving of email. Reissuing of certificate change its Certificate ID & a new certificate record is also added into the account.
Renewal:
On the other hand renewal of certificate may seems pretty much same as purchasing new certificate, but it’s different. Renewal functionality is fully integrated within the module. If the settings of "Payment Type" is set to "Recurring" while creating a product, invoices for renewals will be generated automatically. Once paid, renewal of SSL certificates will be created automatically as well. Though one thing to note is that, after the renewal of SSL still activation is required through CSR.
Now one important thing is that, if you renew it before actual expiry date, like in your situation before 2 months, your new certificate will have expiration date one (or several, if you choose to be more than one year duration) year from the expiration date of the initial SSL certificate, so you will not lose any time on it.
If a certificate issuer issues a certificate that has an expiration that occurs after the expiration of the issuer's own certificate, will the issued certificate still be valid after the issuer's certificate has expired?
To be more clear, let me give an example:
I = The Issuer
C = The issued certificate
if I created C in 2007 with an expiration date of 2017
and I's certificate expires in 2010
will C's certificate be valid in 2012?
Just to give an authorative source for what the others have already said:
RFC 5280 states in section 6.1.3
The basic path processing actions to be performed for certificate i
(for all i in [1..n]) are listed below.
One of these actions is to verify (2)
The certificate validity period includes the current time.
The notion of current time is interesting here - for example, if in 2012 you receive a document that was signed in 2010 and additionally carries a RFC3161 timestamp on it, then the signature is to be considered valid, because both I and C were valid at the "current time" (2010). Without the timestamp, however, you would have to reject the signature because lacking cryptographically reliable information on the time of signing, your only chance is to assume "now" as the "current time"; and in 2012, I was no longer valid.
Clients should check each certificate in the chain for validity. So, if you have a root that issues a certificate to a signing CA which issues your identify certificate, your client would need to check to ensure that your identity certificate is valid (still in valid date period and not revoked), then your signing CA's certificate is valid (still in valid date period and not revoked), and then the root (still in valid date period and not revoked and, hopefully, be in your trust store as that's the only way you would trust this chain anyway).
So, basically, every certificate in the chain must remain valid for your certificate to be valid. If the issuer's certificate expires before the issued certificate, the issued certificate should not be valid.
I've read about SSL protocol and now, I know how it encrypts data. But there is something I couldn't understand. With SSL , you're sure you're sending data to and getting data from correct server. But how?
I mean if I create a fake certificate and send it for requests of special website, how do browsers ( or other programs) detect the fake certificate?
Edit: I didn't mean to create a self-signed certificate. I meant how can someone validate my certificate if I create a certificate that its issuer and subject ,etc are something to real certificate! (the only things that are not real is Public key & signature)
TL;DR summary:
Validity of a server certificate is established by:
Host name verification
Verifying the signatures of the entire certificate chain
Performing additional checks on meta data for each certificate
Checking the revocation status of each of the certificates involved
Checking whether the self-signed root certificate of the chain is among the certificates that one trusts by default
Explanation
Let's assume you want to connect to https://mail.google.com (you can try this out in your browser!).
The (real) server will respond with a certificate that is issued to mail.google.com, i.e. in the 'Subject' field of the certificate you will find the Common Name (CN) 'mail.google.com' - cf. RFC 5280 for details on the fields of certificates. The fact that the subject is linked to the site URL is very important for the security of the whole model, and it is actively checked by your TLS implementation ("host name verification"), because otherwise there would be room for Man-In-The-Middle attacks. I.e. somebody could acquire an otherwise valid certificate and impersonate mail.google.com without you taking any notice of it.
In addition to the host name verification, your TLS implementation will also check the "validity" of the certificate. The whole procedure is rather complex and does include checking the trustworthiness of the certificate, but additionally a lot of other things will be checked, more on that in a minute.
If you view Google Mail's certificate in your browser, you will notice that there are actually three certificates shown:
mail.google.com
Thawte SGC CA
Class 3 Public Primary Certification Authority (VeriSign)
The model is that there are a few (well, unfortunately not so few anymore) trusted root certificate authorities ("root CAs") that either you could choose on your own or (more likely) that come preconfigued with your software (e.g. browser) that are blindly trusted. These trusted authorities form the anchors of the entire trust model of "PKI" (Public Key Infrastructure). The basic idea is that the trusted entities may issue certificates to other authorities and grant them permission to again issue certificates (these authorities are called intermediate certificate authorities). The intermediate CAs may again recursively apply this procedure up to a certain point, the number of intermediate CAs between an actual end entity certificate and a root CA certificate is generally limited.
At one point, an intermediate CA will issue certificates to an "end entity" ("mail.google.com" in our example). Now the process of issuing a certificate actually means that the party requesting a certificate will create a public/private key pair first, and use them to authenticate a certificate request that is sent to the certificate authority. The issuing authority creates a certificate for the subordinate entity (either intermediate CA or end entity) by "signing" that certificate using its own private key using an asymmetric algorithm such as RSA and by additionally including the public key of the requesting party within the newly generated certificate. The root CA possesses a so called self-signed certificate, i.e. the root CA is the only authority that may sign their own certificate and include their own public key. The private key remains hidden at all times, of course.
The recursive nature of the certificate issuing process implies that for each end entity certificate there is a unique way of establishing a "chain" of certificates that leads up to a root certificate authority. Now when you are presented with an end entity certificate while trying to connect to a TLS-secured site, the following procedure will be applied recursively until you end up with a root CA certificate:
Find the certificate of the authority that issued the certificate to be validated (see RFC 5280 for details). If none is found: exit with error.
Take the public key of the issuing certificate and verify the signature of the to-be-validated certificate using this public key.
Check a lot of additional things such as whether the certificate has neither expired nor is it not valid yet, "policy constraints", "key usages", "extended key usages"... (again, the gory details are in the RFC).
Certificate revocation status (more on that later)
If all checks were positive, you will ultimately end up with a certificate being self-signed, i.e. where the subject is also the issuer (such as the VeriSign certificate in our example). Now the last thing you have to verify is whether this certificate is among those that you blindly trust: if it is, all is well and the connection will succeed, if it is not, the connection attempt will be rejected.
As if this were not complicated enough already, the checks described so far do not handle cases where once valid certificates suddenly become rogue, examples being cases where a certificate is stolen or private keys are compromised (think of Comodo and DigiNotar). In these cases, the normal procedure is to "revoke" those certificates gone bad, that is you want to mark them as being invalid starting from a distinct point in time (they will expire at some point anyway, but for the remainder of that period they shall already be marked as invalid). For these cases, CAs have the possibility to issue CRLs (a catalog of certificates declared as invalid) or OCSP responses (information for one or in rare cases a set of certificates) that provides clients with information whether a given certificate has been marked as invalid or not. The revocation status needs to be checked for all certificates in a chain, should one of them be marked as invalid then the end entity certificate cannot be trusted and the connection must be rejected as well.
SSL certificates are signed by a certificate authority (CA), which is someone the user already trusts (or more likely, the people who designed their operating system trusts).
The CA digitally signs the certificate using public key encryption. The basic explanation is that the CA has a "private key", and a "public key" that everyone knows. Via some math I don't understand, the CA can create a signature using its private key which can easily be verified with its public key (but the public key can't be used to create a new signature).
When you get an SSL certificate from a server, you get the server's public key, and a signature from a CA saying that it's valid (along with some other info). If you know and trust that CA, you can check the signature and determine if it's valid. You can also use a certificate revocation list to make sure it wasn't revoked.
So basically, you can recognize a bad SSL certificate because it isn't signed by a certificate authority that you trust.
Any fake certificate you create will be a self-signed certificate.
The browser will display big scary warnings when connecting to a site with a self-signed certificate which the user will promptly ignore.
In order to avoid warnings, you need a certificate signed by a certificate authority that the browser trusts, such as VeriSign.
These companies will hopefully make sure that you actually own the domain for the certificate they're signing.
Re: Edit: You can only create a non-self-signed certificate if you get it signed from a trusted CA.
They will refuse to sign a certificate for a different subject.
Process from my understanding:
server sends servers public key
server sends certificate (all information encrypted by trusted CA with their private key)
Your PC decrypts certificate with public key (built into OS from trusted CA)
Your PC hashes (with sha1 and sha256) the servers public key
Your PC compares the hashes of servers public key with certificate stored hash, if not same browser will block site
Your PC compares allowed domains from certificate and the domain, if not allowed, if not same browser will block site
Your PC compares valid date from certificate and your date, if not valid browser will block site.
To fake this you would either need to:
obtain a CA private key (extremely hard to get),
be a CA,
be part of the 5 eyes (Government intelligence agency alliance) and ask a CA for their private key
So if you see a padlock in the address bar you are almost always safe.
Certificates work because they follow a chain of trust. Certificates have a chain of one or more issuers that are trusted; this chain is the backbone of why it works at all. Browsers and nearly all SSL certificate libraries do this chain check, or at least provide the option to.
Self-signed certificates (or those issued by chains that end in a self-signed certificate) would fail this check.
I'm designing a system where users will be able to register and afterward authenticate with client certificates in addition to username/password authentication.
The client certificates will have to be valid certificates issued by a configured list of certificate authorities and will be checked (validated) when presented.
In the registration phase, I need to store part(s) of the client certificate in a user repository (DB, LDAP, whatever) so that I can map the user who authenticates with client certificate to an internal "user".
One fairly obvious choice would be to use certificate fingerprint; But fingerprint itself is not enough, since collisions may occur (even though they're not probable), so we need to store additional information from the certificate. This SO question is also informative in this regard.
RFC 2459 defines (4.1.2.2) that certificate serial number must be unique within a given CA.
With all of this combined, I'm thinking of storing certificate serial number and certificate issuer for each registered user. Given that client certificates will be verified and valid, this should uniquely identify each client certificate. That way, even when client certificate is renewed, it would still be valid (serial number stays the same, and so does the issuer).
Did I miss something?
You have several solutions:
Storing a fingerprint.
Yes you are right, a collision is theoretically possible but the probability is really really low and you can consider it does not happen : 2 users in your system will not have accidentally the same certificate fingerprint. However hash algorithms are getting weaker over time and an attacker may try to forge a certificate whose fingerprint matches a registered one. This attack is called second preimage attack and is pretty hard to do since the attacker does not try to forge some random data matching the fingerprint but a real X.509 certificate which can pass the initial validation phase (i.e. hacking the PKI). Pretty hard :) But if you really want to prevent yourself against collision you can store 2 fingerprints with 2 distinct algorithms (e.g. SHA-1 and SHA-256).
Storing the certificate issuer and serial number. Yes it can be used as a unique certificate identifier. As you wrote, the standard (RFC 5280 obsoletes RFC 2459) indicates [The serial number] MUST be unique for each certificate issued by a given CA. However it also means that when the certificate is renewed the serial number changes since a new certificate is issued by the CA.
A final remark: you want to handle certificate renewal and it is a good idea, a lot of software editor forget that certificates have to be renewed. But you must be aware that almost everything may change in the certificate: the subjet name (people may change their name, women get married...), the issuer name (the certificate supplier company may change...), the key algorithm, the key size, the extensions... In your system the certificate renewal process will probably be pretty close to the initial user certificate registration.
The best way to uniquely identify a user is by email address. In the registration process a valid email address must be mandatory. Then you associate the certificate serial number and issuer or perhaps a hash of the the certificate itself with the email and the user id. Then, when the certificate expires or the user changes the certificate he/she will have a "renew certificate link" where he enters the email address and he receives a link to upload the new certificate. You can then replace the old serial/issuer with the new one.
I decided to concatenate the issuer name, a delimiter |, and the DN.
Hopefully, this solves the problem of using serial numbers which change on renewal.