Tag Info

Hot answers tagged

177

It is already done: It is the FPKI root CA, under explicit and full control of the US government. Windows already trusts it by default. Before you flip out and begin to delete root CA certificates, burn your computer's motherboard, or drink a gallon of vodka, think about what it means. It means that the US government could technically emit a fake ...


32

The NSA could and probably already has gone -- using a USA PATRIOT Act demand letter, or other similar legislative tool -- to all the major CAs in the United States (e.g. VeriSign, GeoTrust, etc.) and demanded that they remit their private root keys to "No Such Agency", "for purposes of 'national security'". Of course, all such requests must (per PATRIOT ...


24

Last year, I made a bet with a friend that I can get a browser-trusted certificate with his domain name in order to launch a successful MiTM attack on his login form to steal his password. Long story short: I lost the bet; I wasn't able to convince any of the 16 CAs I contacted that I'm the legitimate owner of the domain. Even though I had an email account ...


13

No. In addition to the obvious government Root CAs in your trust stores; the NSA is a spy agency and as such has likely already stolen the private keys of several other CAs. If they are devious, they'd steal the private keys of other government CAs for potential false flag operations. Additionally, unless every operating system and browser explicitly locks ...


11

This looks like a poorly encoded name which was even more poorly decoded and reencoded. Initially, the name seems to be: A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH The name was then encoded in big-endian UTF-16. In this case, this means that every character yielded two bytes, the first of which having value 0. Upon decoding, whatever ...


11

Depending on how the CA does things, it may or may not have a copy of your private key. Usually it doesn't. The normal method is that you generate your private/public key pair on your own machine, then send the public key to the CA as part of a certificate request. The CA assembles and signs the certificate, and sends it back to you. Your private key never ...


10

So we had to install their root certificate "PrivateCompany Root CA" to our web server. Why? Globally trusted CAs are useful in general purpose clients like browsers. But if you consume specific web services from a custom client you can add that CA locally. Every decent SSL client allows you to influence certificate validation. For example by ...


7

All or None. The singly-rooted CA trust paradigm we inherited from the 90s is almost entirely broken. Vanilla browsers do not track or alert if the Certificate Authority backing a SSL certificate of site has changed, if the old and new CA are both recognised by the browser1. As the average computer trusts over a hundred root certificates from several ...


7

There is no risk of compromising the private key, because you send only the CSR which contains the public, but not the private key. But using a CA is in effect a trust delegation, as people trust your certificate because they (or the browser) trust the CA that signed the certificate. Once they notice that the CA is no longer trustworthy (like DigiNotar after ...


7

You can add, for example the -sha256 flag to the OpenSSL command line when generating the CSR. I don't believe any CA will change how they sign your CSR based on this, and it certainly won't affect the certificate chain. They're not resigning the cert chain for each key, the only signature operation they do is on your CSR itself. Any intermediate/root CAs ...


6

As Rook said, the statement "Bob requests Alice' public signature verification key from CA. CA returns Alice' key..." is incorrect. Public Key Infrastructure does not require a CA to serve as a public key server. What would actually happen is that Bob would ask Alice for her public key. Alice would send her public key directly to Bob, signed by the CA. Bob ...


6

Generally speaking, you are the one who should decide who you trust and who you do not trust. However, this is a tiresome process; in its infinite wisdom, Microsoft (or Mozilla or Google or...) found it fit to include a set of "default trusted roots" that are used by Internet Explorer (or Firefox or Chrome or...). In the case of Microsoft, the process by ...


6

The problem with self-signed certificates is that anyone can create them for any name they want. When you issue a self-signed certificate for yourself, the identity of that certificate can read whatever you want. You could create a certificate which reads "Qmal", or one which reads "Google Inc." or "Western Union". That means it provides no security ...


6

To be intentionally recognized, the trusted certificate authorities (CAs) will need to get their root certificates pre-bundled with specific web browsers and operating systems (OS), like Microsoft Internet Explorer, Apple Safari, Mozilla Firefox, Google Chrome and Opera (et al.). The trusted root certificate list is usually updated periodically to add or ...


6

The question is... a bit complex. The critical issues are existence and availability of intermediate CA certificates. Consider the following points: Root CA are not "revoked". Revocation is a mechanism by which the issuer for a given certificate specifies, directly or indirectly, that one of its issued certificates is not to be trusted and must not be used ...


6

... But in reality, a self-signed cert is not significantly less secure than a cert signed by a CA - in the sense that your traffic is encrypted and sent to the web server and decrypted there. It just means that no one "trusted" checked the identity of the webserver in question. This just is a very important part. If you don't verify, that the peer you ...


6

From RFC 5280 3.3 Revocation An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. If you have a lot of changes (people leaving etc.) it's best to not make the certificate validity too long otherwise the CRL can grow large (some CRLs are > 30MB which ...


6

There is only full trust with the CAs you've installed. This means, that there is no restriction which certificates a trusted CA can sign. So it can also sign fake certificates for sites they don't own (e.g. banking.com) and you will accept them. I don't know how you communicate with the partner, but with languages like Perl, Python etc you can specify a CA ...


5

There is no World Overlord because there are too many candidates for the post. The whole X.509 protocol is completely up to the task of having a single root CA. However, there is no single root CA because people could not agree about who should thus be entrusted with complete power over all certificates. Or, from another point of view, there is a Global ...


5

Short answer: because RFC 3280, its predecessor, says so. Longer answer: because historically ASN.1 encoders/decoders have had problems with properly encoding and decoding integers. X.509 uses DER encoded ASN.1, which amongst other things, means that the data must be encoded in its minimal (shortest) form. As integers are stored in a variable length ...


5

The risk of using a shifty-looking CA is not in the certificate enrollment process: as long as you generate the key pair yourself and send only the certificate request to the CA (which contains only the public key) and receive the raw certificate in return (not a PKCS#12/PFX archive), then your private key is yours and yours only. The risk, though, is in ...


5

You are correct that SSL uses a asymmetric key pair. One public and one private key is generated which also known as public key infrastructure (PKI). The public key is what is distributed to the world, and is used to encrypt the data. Only the private key can actually decrypt the data though. Example time. Say we both go to walmart.com and buy stuff. ...


5

Yes, it is possible, but the better question is would they? The CA's reputation is their life blood. Why would they give a trusted signing authority to another CA that might not hold up to their standards (and could be a direct competitor in the future.) To the best of my knowledge, no CA offers this kind of service, nor do I see any reason why they would ...


5

To answer your first question: As far as I know, there is no way to circumvent this. It's a security feature. To answer your second question: Yes, non-default trusted root certs are definitely potentially problematic. They are often abused. They are sometimes used for workplace or traffic monitoring (which is potentially OK if adequately disclosed, ...


5

There is no global directory of all issued certificates (X.509 was designed to support the Directory, but it never existed in practice). You will have to contact "all CA" and ask them nicely. Basically, this would mean going to their site, and using the "I lost my password" feature so as to regain control of your account, if it exists. Details vary depending ...


4

PKI-based signature and encryption works this way (in email and any other application): When signing data, you need access to the private key When validating signed data, you need access to the public key When encrypting data, you need the public key When decrypting data, you need access to the private key. Now, a (X509) certificate is a set of data that ...


4

To view your certificate stores, run certmgr.msc as described there. The "root" store contains the root CA, i.e. the CA which are trusted a priori. certmgr.msc shows you an aggregate view of all root CA which apply to the current user; internally, there are several relevant stores (the "local machine" stores apply to all users, the "current user" stores are ...


4

This is not encryption that you need. Well, you might need it too, but that won't do the whole job. Encryption is for confidentiality: you encrypt the token if you don't want the client to learn the token contents, i.e. his permissions. Maybe you indeed want to hide that information from the client, but that's a secondary concern. The primary security ...


4

This is most likely an obsolete "bridge" now leading to the wrong place. There are two valid trust chains for this cert. There is a root cert for GeoTrust Global CA, valid from 2002, which is in current Windows/IE and Firefox stores (and Java); and also a "cross-signed" cert for that CA under Equifax Global CA as follows: Data: Version: 3 (0x2) ...


4

As far as X.509 is concerned, there is absolutely no problem in having several certificates with the same public key. The validation process is described in full details here; in a nutshell, it is verified that: each certificate in the chain is currently valid (with regards to its start and end dates for validity); the signature on each certificate is ...



Only top voted, non community-wiki answers of a minimum length are eligible