This is an existing question only. But i dont get exact clear details on this question.
We are using TCPDF to generate PDF with signatures. And for testing purpose we have generated self signed certificate to generate signature fields and make it work.
But we want to move it to live server. So we have to suggest our client to purchase trusted certificate for this purpose.
So my question is,
What type of certificate do our client had to purchase?
Whether we can use the SSL certificate for this purpose?
If not means, where can we purchase it and what are the details do we need to know before purchase?
Please anyone provide me detail explanation on the above
In layman's terms, this depends on the country you are in. There are Signature Issuing authorities, also call Certifying Authority (CA). CA may offer various types of signature after various types of authentication method for Individuals and Corporations or Institutions.
You may search for Certifying Authority (CA) in your country and follow their procedure to get legally (binding) valid Digital Signature.
Certificates for digital signatures are available from CAs (Certificate Authorities). Unfortunately, the CAs often charge a lot of money for such certificates.
"Code-signing" certificates won't work for digitally signing documents.
You can also get certificates for digital signatures from a couple of countries:
Estonia's e-residency program provides a digital signing certificate on a smart card to anyone after paying €100. The cert is good for 5 years. (You don't need to open a business in Estonia, that's just what they hope you do with the card.)
The card will be given to you at your local Estonia embassy or consulate after they verify your identity via your passport.
SuisseID -- from Switzerland, also available to anyone. Valid for 3 years, CHF 146.60 ($148)
Related
I have an online shop and I've just installed a new SSL certificate and it was free. It does seem too good to be true. I'm a very cynical type of person.
I don't know about different types of SSL, but I just need to be able to accept payment data (I'm using a PayPal add-in on Opencart).
I got my certificate from letsencrypt and they don't explain much on there website.
But if you go to my website Gwenllian-retail you will see the certificate. Can I handle financial transactions with that?
If not what type of SSL do I need?
One does not need much money or complicated software to create valid SSL certificates. I could create my own with ease, if I wanted. In fact, I have done. There is no reason to think that LetsEncrypt certificates are somehow of a wrong kind.
The question is whether people will trust those certificates, and that comes back to whether they trust the Certificate Authority (CA) that signed them. If I sign my own certificate and present that to someone as proof of my identity then that other party has no more reason to trust that the data within accurately identify me than if I just told them directly.
LetsEncrypt serves as the CA for SSL certificates it provides. I have never relied on them for a certificate, but according to hosting company DreamHost, LetsEncrypt certificates are trusted by all major browsers. (LetsEncrypt makes the same claim about itself, too.)
Again, all this trust business is mostly about authentication: whether the entity that presents the certificate (your web site) is really the entity that it says it is. It is not about the nature or quality of the encryption with which the session is secured. That comes down to the capabilities of the two endpoints, and is largely independent of the certificate.
Let's Encrypt is a well known service backed up by many big players. So yes, it's OK to use it in on your site. BUT ! SSL certificate is not everything, it's only one of many shields to protect you application.
0) I'm not sure if I'm reading the whitepaper correctly, there's a chapter on Certificate Authorities, so I assume that the white paper would teach me how to digitally sign a pdf. But page 68 appears to only show that the document is signed but it doesn't do "certify documents" are authentic.
I'm reading page 68 of this article
http://itextpdf.com/book/digitalsignatures
I want to also comment that the two signatures can be a source of confusion to anyone looking at the pdf. The first confusion MY end users will ask is:
a) why are there two certificates (I've read it and understand the reason why there's two certificates) where one says one thing but the other says another?
What's concerning is that Bruno Lowagie's certificate is marked as NOT trusted as a "sign documents or data" and pdf is NOT trusted for "Certify Documents" What I'm trying to say is, it's very confusing to end users when they click on the certificates and see that one is trusted and the other is not. Figure 3.3 vs. 3.4. page 68.
The certificates are aligned as such:
Cert Signing Authority <supp
Bruno Lowagie <bruno#low
Conversely, someone sent me a sample of a pdf that has only ONE certificate, and it says "Certified by [HIS COMPANY NAME]" then when you click on Show Signer's Certificate, on the left column you'll see the following:
Adobe Root CA
GlobalSign CA for Adobe
HIS COMPANY NAME
Here, you click though any of the above levels Adobe Root CA, GlobalSign CA for Adobe, and HIS COMPANY NAME; they ALL say certificate is trusted to "sign documents or data, certify documents." This consistency makes sense.
I have not played around with the code yet, but is it possible to use itext and make it look like what I see in my friend's sample pdf?
If I'm going to pay for the itext license, I want to make sure that I'm able to programmatically digitally sign the pdf with CA certificates and that the Trusts would ALL look consistent, which makes sense.
If there is only one certificate, you are confronted with a self-signed certificate. Self-signed certificates should never be used to sign a document. The only self-signed certificate that should be trusted is the root certificate of a Certificate Authority (e.g. the Adobe Root Certificate, the GlobalSign root certificate,...).
These certificates are kept in a vault under very high security. They are NEVER used to sign a document. They are used to issue intermediate certificates.
In your example, you mention the "Adobe Root CA". GlobalSign paid Adobe a lot of money for Adobe to use this certificate to issue the intermediate certificate "GlobalSign CA for Adobe". GlobalSign makes money using this certificate to issue certificates for companies who buy an HSM or a USB token (in case of a USB token, there's even one extra certificate in the certificate chain).
This is how it works. If you have read my whitepaper, you have missed the part where the concept of having a Certificate Authority (CA) is explained. If you would send me a signed document, and I would NOT see a certificate issued by a CA, I would NOT accept your document. I would demand that you either use a certificate under the Certified Document Services (CDS) with Adobe's certificate in the Root, or I would ask you to use a certificate of which the root certificate can be found in Adobe's Approved Trusted List (AATL).
If I would only see your company name in the certificate chain, I would NOT accept your document. Your allegation that I would be confused when I see Adobe's or GlobalSign's certificate is wrong. The opposite is true: I need to see a certificate from a CA before I can trust your signature.
Self-signed certificates will never automatically result in a green check mark. To get a green check mark automatically, you need a certificate that is issued by a CA. This CA should be a member of either CDS or AATL. This means that the certificate will need to meet or exceed FIPS 140-1 Level 2. This implies that you'll need to invest in either a Hardware Security Module (HSM) or a USB token.
You will not succeed in getting an automatically trusted "green check mark" signature using a software certificate (PKCS#12), not with iText, not with any other software.
HSM:
USB Token:
I made an application, which communicates over the. net SSLStream, and for developing I used makecert.exe to create a self signed ssl certificate. Now Ive read in some microsoft article, that makecert should be used for testing only.
Now my question is: is the application safe with this cert, or which program can i make a safe and comparible cert?Any help will be greatly appreciated
Edit: The self signed Certificate is hardcoded into the client application and it compares it everytime it establish a connection, so man-in-the-middle attack couldnt work, but how random are the makecert Certificates?
I would recommend using OpenSSL to create a self-signed certificate used for production environment. I've never made thoughts about makecert.exe. To be honest: You want to achieve an encrypted transfer of your data using SSL between your Application and the server.
The hole certificate wont be displayed to the "user/customer". The only reason nowadays is to embedd a badge with "this is a secure page" to the page on which SSL is enabled.
If you are looking for this, you will definitely need a signed Certificate from a CA. If you are thinking about this, i recommend StartSSL, because it's far the cheapest and offers you for one time validation nearly unlimited wildcard certificates. Its trusted by microsoft and you can create a code-signing-cerficiate for free. (Onetime fee for validation only).
Concerning the randomness and security of the certificate:
If you are validating the fingerprint of the certificate you are connecting to, there should be less security concerns. (i.e. Fiddler won't work this way).
SSL is based on RSA Algorithm so when generating a private/public keypair with a keysize of 2048 or even 4096 (max. on StartSSL) there shouldn't be any security concerns. How to create the Certificate you will find here If you wont trust RSA, you shoudn't trust anyone ;)
Keep in mind that most universities using self signed certificates created using OpenSSL. Its now FIPS certificated and allowes you a wide bunch of settings to achieve fit your system.
It's safe if you find some secure way to get the certificate to everyone who uses your application. Otherwise, they'll have no way to know they're really talking to your application. Anyone else can run makecert just like you did, and nobody will have any way to know whether they're really talking to you. A certificate issued by a CA bind your identity to a certificate, allowing clients to know they're really talking to the right service.
When you punch https://www.amazon.com into your browser, how do you know you're sending your credit card information to Amazon and not an imposter? Well, Amazon has a certificate that was issued for www.amazon.com by a certification authority. An imposter could not get such a certificate -- the authority wouldn't issue it.
But if Amazon used a self-signed certificate ... well, anyone can do that. So how would I know I was actually talking to Amazon? I would have to know ahead of time which self-signed certificate that claimed to be for www.amazon.com was the right one. I wouldn't have a CA's stamp of approval to tell me.
you hardcoded your password (as a long cert) into your application, and you are asking if it's safe?
all I need is a copy of your code or wherever you stored it and I can hack all the apps you ever write. plus you cannot update or change it.
Self-signed certificates say essentially "I certify that I am I. Signed: I". Look up how to set up you own certificate authority (it depends on your choosen environment, and there are several options). Use that authority to issue certificates, and set the servers and clients to trust your CA. No need to pay $$$$ for them, plus you know exactly under what conditions you hand out certificates.
I have been reading up on the technical basics of how SSL works (which was surprisingly hard to find inside the ocean of laymen/non-technical articles/tutorial/videos out there). I have 3 small questions that in and of themselves felt too small to clutter SO with but as a whole I think provide some insight into how SSL works and address issues that don't seem to be well-documented:
Why (not when or how!) do SSL certificates expire? These are just public/private key pairs operating on a cipher/algorithm like AES. I assume there's a financial/business incentive behind the scenes here?!?
How many SSL certificates does an organization need? And before you say "that depends on your organization", I guess at the core of this question is: what driving factors make a company say, oh, I guess we're going to need another cert, or 10 more certs, etc. In other words: why is 1 cert often not sufficient for an organization??
Why does a company ask a CA for a root certificate and then get child certificates off of that root? What benefits does this "Certificate Tree" provide? (As opposed to just getting separate certs.)?
Thanks in advance!
1) Why do SSL certificates expire?
When a certificate expires, you're basically saying that this public/private keypair has been abandoned. Technically, you can still use this certificate to encrypt data, but the expiration date is there to mitigate revocations among other things. Additionally, however, in the X.509 spec there are specific reasons outlined for expiration:
4.1.2.5 Validity
The certificate validity period is the time interval during which the
CA warrants that it will maintain information about the status of the
certificate.
CAs publish revocation status information about a certificate and that means they need to keep track of them. When a certificate expires, the CA has done their part for the term of the certificate and stops tracking information for that certificate. You are essentially paying the CA to say with authority that this certificate is valid.
There are other reasons for expiration too. If I was still using a certificate signed in 2002 (which would be possible), the level of encryption probably wouldn't be up to standards used today. By setting an endpoint for the certificate, you are also setting a date on which you need to upgrade.
Now, of course, I don't think you can deny one of the biggest motivators behind the expiration is money [citation needed], but there are at least some technical and reasonable ideas behind it.
2) How many SSL certificates does an organization need / what driving factors help them decide?
It does depend on your organization. A traditional SSL certificate is matched to a domain name. However, anything can be signed with a key pair (developer certificates, etc.). So, for SSL, it'll depend on the number of domains you want to protect. For a traditional cert, www.domain.com and example.domain.com are completely different entities. There are other types of certs that can purchased, like wildcard certs, etc. that will depend on the needs of your business. Seriously, you can get incredibly complex or incredibly simple. Here's a rundown on some of the basic and different types for protecting a website: SSL Certificate Types
3) What benefits does [having a] "Certificate Tree" provide, as opposed to just getting separate certs?
You are basically saying that you trust this CA to generate certificates. That's why browsers have to have the root CA installed to accept a certificate. They are saying, "I trust this authority has only signed certificates for valid and trusted sources."
In practice, it ends up not being the case as a lot of CAs don't rigorously check who they are giving certificates to before issuance. Not always, but it does mitigate some of the danger. The problem is when the CA root certificate private key is compromised because then anyone can fake a legitimate certificate.
Hopefully this answers some of your questions.
A friend of mine asked me why we pay so much for SSL certificates if everyone could theoretically issue one. Why indeed? And how do we judge if the little lock in the browser is really trustworthy?
Certificates are cryptographically signed by something called a Certificate Authority(CA), and each browser has a list of CAs it implicitly trusts. These CAs are entities that have a set of cryptographic keys that can be used to sign any certificate, often for a fee. Any certificate signed by a CA in the trusted list will give a lock on a browser, because it's proven to be "trusted" and belongs to that domain.
You can self-sign a certificate, but the browser will warn you that the signer is not trusted, either by showing a big error box before allowing you in, or showing a broken lock icon.
In addition, even a trusted certificate will give an error if it's used for the wrong domain, or is modified to include another domain. This is ensured because the certificate includes the domains it is allowed to be used for, and it also has a cryptographic checksum/fingerprint that ensures its integrity.
This is not 100% safe at the moment, as there is the possibility to fake CA certificates that use MD5, see this link: http://www.phreedom.org/research/rogue-ca/. Though it has to be noted that this is pretty hard, as they exploited a weakness in an already existing CA, which may or may not have been closed by now.
In essence, we trust the certificates as much as we trust that our browser providers know how to select "proper" CAs. Those CAs are only trusted on virtue of their reputation, as a single misstep theoretically would be a very heavy blow on their trustworthiness if detected.
The whole CA business is amazing. I've purchased a couple of certificates from rapidssl.com, and all the "proof" they required was:
I could receive mail to the domain.
I could answer my phone.
That was it. Keep in mind, when trusting the little locks in the browser.
First, some background on strong public/private key cryptography, which SSL is based on:
A key has two parts, the private part and the public part. The public key can be used to encrypt material that requires the private key to decrypt. This allows the use of open communication channels to communicate securely.
One important aspect of public/private key cryptography is that the private key can be used to digitally sign a message which can be verified using the public key. This gives the receiver of a message the ability to verify concretely that the message they received was sent by the sender (the holder of the key).
The key to SSL certificates is that encryption keys themselves can be digitally signed.
A "certificate" is composed of a private/public key pair as well as digitally signed data. When someone buys an SSL certificate they generate a private/public key and submit the public key to a Certification Authority (CA) to be signed. The CA performs an appropriate level of due diligence on the buyer of the SSL certificate and signs the certificate with their private key. The SSL certificate will be bound to a particular website or set of websites and is essentially the CA indicating that they trust the owner of the private key of the certificate to be the proper owner of those websites.
The root certificates (public keys and other meta-data) for trusted CAs are included by default in major shipping browsers and operating systems (in windows, type "certmgr.msc" into a run prompt to see the certificate manager). When you connect to a web server using SSL the server will send you its SSL certificate including the public key and other meta data, all of which is signed by the CA. Your browser is able to verify the validity of the certificate, through the signature and the preloaded root certificates. This creates a chain of trust between the CA and the web server you are connecting to.
Because we have to trust someone.
Trusted SSL certificates have signatures of trusted authorities. For example, VeriSign has a deal with Microsoft, that their certificate is built in your browser. So you can trust every page with a VeriSign trusted certificate.
This graphic really picks the point:
RA = Registration Authority
CA = Certification Authority
VA = Validation Authority
Rough outline: A user applies for a
certificate with his public key at a
registration authority (RA). The
latter confirms the user's identity to
the certification authority (CA) which
in turn issues the certificate. The
user can then digitally sign a
contract using his new certificate.
His identity is then checked by the
contracting party with a validation
authority (VA) which again receives
information about issued certificates
by the certification authority.
If you are not using one of the accepted CAs people will get a message box when accessing the site talking about an untrusted certificate. That won't help to generate traffic to the site.
The lock only means that the site owner showed a CA some kind of proof that he really is who he claims to be. You must judge on your own if you trust that person/site.
It's like a stranger showing you a photo ID. Do you trust him more because you know for sure his name is John Doe? Probably not.
But when people you trust told you: "John Doe" is a good guy. The proof that the guy in front of you actually IS "John Doe", than you might choose to trust him as well.
Why? Because you're paying to ride along on someone elses reputation.... to vouch for you.
Its all about whose validating your claim to be you. Despite some of the documentaries Ive watched lately, and the recession, I'm still more likely to believe corporate America when they confirm your identity to me, than I am the Russian mafia. Even though both can just as easily issue certificates.
The amount you pay is basically just (how much it costs them to secure that reputation and/or suppress any security breaches) + (however much they can afford to gouge the market as a margin %).
Now the barriers to entry are quite high, cos its really expensive to earn that trust, so theres not a lot of competition. Therefore chances are the price isn't going to fall anytime soon.... unless Sony or GE etc decide to play.
You pay for a certificate so that when you go HTTPS (which you should for anything a little sensitive) your clients don’t get big warnings and go call your support saying that you have infected them & al…
Very little security, lot of FUD.
If you have the possibility of giving your clients your own certificate directly, do it. But it is a rare case.
Let's create an attack scenario.
Suppose the DNS was corrupted and https://facebook.com/ points to attacker's IP.
You sit down to your PC and open Facebook to loose few minutes on pointless scrolling. And then BANG, Certificate invalid error shows on your screen. Attacker signed https://facebook.com/ with his own cert to make sure no one will leave his copied facebook page because it's not encrypted so it looks suspicious. If browser wouldn't check certificate's authority, then attacker could sign corrupted page with his cert and you won't be aware you're connecting to the wrong IP.
So the attacker has 2 options to choose from:
Sign corrupted facebook page with his cert, so users will see an error.
Don't use https on his corrupted page.
Certificates are built on a chain of trust, and if let anyone be a signing authority, we would be implicitly trusting everyone. It's a bit scary today though, since there are over 200 so called "trusted authorities" whose certs are built into your browser!
There is one free CA that I know of though: StartCom. They issue free SSL certs, but they are only accepted in Firefox, not IE. (Not sure about Safari or Opera).
The other answers have explained the CA-system. The perspectives project aims to deploy a new approach to SSL, where you can choose whom to trust: http://perspectives-project.org/