Tag Info

New answers tagged

2

Actually, there is an often unused (at least on the web) optional part of SSL/TLS that allows for client authentication. It is generally not used on the web because the server doesn't really care if the client is who they say they are - they just need to have the proper credentials. Additionally, imagine the nightmare of having to verify every client in the ...


1

"fakebook.com has acquired a certificate from on the trusted CAs" : Normally (and I said normally, because to say it so "the world isn't perfect") this step should not happen. A really trustable CA should benefit from specific services from third-party societies (like Netcraft) so, when you try to register a new domain name, they will automatically check it ...


5

is it trust-worthy because the CA authority did a background check on them? No. A SSL certificate is comparable to a passport: it says who the person is and which country the passport issued. But it does not say how trustworthy the person is. The main use of the certificate is to make end-to-end encryption possible, that is protecting against ...


0

Comodo, which was involved in this fiasco, trusts the following email addresses for domain verification: admin@ administrator@ postmaster@ hostmaster@ webmaster@


0

In practice, the ability to respond to email sent to any email address proves nothing at all, not even that you own the email address in question. All email is subject to tampering by the people who actually control the mail servers it passes through. If I have root access to domain foo.com, I have absolute control over all the email delivered there or ...


7

It's a rather short list: ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ Now that's the fixed and static list. But: contact info from WHOIS is also legal. From the CAB-Forums' Baseline requirements, page 17: 11.1.1 Authorization by Domain Name Registrant For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL ...


1

Generally, the very nature of PKI (and some good system maintenance) should prevent this from being a security risk. But personally, I'm not sure I'd really want just any website to be able to enumerate my Trusted Root CA list. This sounds like a good way to phish out systems vulnerable to attacks using stuff like DigiNotar certs or certificates from other ...


0

Edit: Could I use JavaScript to send a GET or POST request to the server, providing a certificate that the CA I'm checking for has to sign? If the connection fails I'll know that the root CA isn't installed on the client. That's probably the best thing you could do. You still can get false negatives if the TLS handshake fails for some other reason ...


1

No, the web server cannot check to see all the CA's the client has installed. If you have access to the client machine, you can check by viewing the Trusted Root Certification Authorities store.


0

The posts by gowernfawr and BadSkillz address the question fully. Just to throw in a helpful tip so you can make sure your certificate is configured correctly: You can use www.SSLLabs.com to test your configuration. In the "Certification Paths" section the Leaf (Server certificate) and Intermediate Certificate should be "Sent by Server" and the Root should ...


1

The root certificate should be enough. It is the server's responsibility to provide any necessary intermediate certificates. To quote RFC 5246: This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because ...


2

You only need to trust the root CA, the intermediate (and other) certificates will be checked if they are signed by a trusted root CA, or a intermediate that is trusted by a root CA. If that root CA is trusted by you, all certificates signed with that will be trusted by you. For example, when you have a chain [user] → [intermed-1] → [intermed-2] → ...


0

You can write your organization name or EORI number in the place


1

This space is for the type of company you are... such as an LLC, C-Corporation, or Non Profit. If you're unsure, look at your DUNs filing or your state incorporation papers. The person who owns the company or manages the legal paperwork (accounting?) will have this.


2

This is defined in IETF RFC4945, section 6.1 (page 36). It is basically a standardised format for protecting important identifying start and ending sequences of encoded data in plain-text files, known as an encapsulation boundary, that has been around for a long time (since at least RFC934, published in 1984).


0

As it turns out, I asked this question in 2012, but now in 2015, there is actually an attack that makes this possible. Depending on the implementation, clients can be vulnerable to this attack which can allow an attacker, a MiTM to spoof any signed certificate that he wants. https://www.smacktls.com/ provides an in depth explanation of how this works ...


4

I would recommend using a completely separate root for the external and internal certificates, to prevent any information leak about internal hosts or users, through Root01, but also prevent any implicit trust by broken software. By using 2 separate root for external and internal use, theres no possible for any trust to leak from External to Internal ...


10

There are multiple ways to exploit a compromised certificate. If you have a compromised website certificate, you need to get people onto your server when they type the address of the compromised one. This can be done: By getting control of a DNS server, there you can basically change the association of a website URL to your server IP address. By ...


0

The basic protocol for getting a singed certificate from a CA is the following: Requester generates a key pair (a private key and a public key) The private key is put aside and should never leave the computer Requester generates a Certificate Signing Request (CSR) which contains basic information that will go into the final certificate (Distinguished ...


-1

Yes, it's presently on track to be defined as an extension of HTTP/2 by http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-06, and actual browser support is being written/committed/supported (bmo #1003448) and enabled (bmo #1113790) as of late 2014 and early 2015, as per http://daniel.haxx.se/blog/2015/03/06/tls-in-http2/, which points out that upcoming ...


2

Trial certs There are several CAs that will generate short-lived trial certificates for you. Here's one: https://www.instantssl.com/free-ssl-certificate.html Short certs And there are some CAs that will generate longer lived free certificates for you. StartCOM/StartSSL has been doing this for several years. https://www.startssl.com/ StartCom on Wikipedia ...


1

You can use OpenSSL to generate your own personal certificate authority that you can use for testing purposes. Here is one example: http://www.dylanbeattie.net/docs/openssl_iis_ssl_howto.html


1

Assuming they're not evil, their MITM firewall will generally have the same set of trusted root certificates as your OS so any real MITM attacks or invalid certificates will be rejected by their MITM firewall. It's not possible to "add" their certificate at the end. They will directly generate a new certificate for the destination website signed with their ...


1

I ran out of space on my previous answer, but think this is valid and useful information: Revocation The next few sections discuss CRL and certificates, but before you get too far I want to draw your attention to an issue that may affect production and PKI operations: If you think your PKI will revoke twice the same certificate with Microsoft's PKI ...


2

"End Entity" is defined in X.509 (well,RFC 5280) as: end entity: user of PKI certificates and/or end user system that is the subject of a certificate; but the expression really makes sense in the context of path validation: an "EE" certificate is called that way because when it appears in a certificate path, it is necessarily at the end of ...


3

You should see the certificate infrastructure (that is to say the PKI, Public Key Infrastructur) as a web of trust. When you are communicating with multiple persons, which wants to mutually authenticated themselves (and their websites), you first choose a common trusted person. This third person becomes a "Trusted Third Party" and will be called the ...


0

What the application should do after setting up the connection is to check the validity of the received cert. You could do this with a nod to pki, ie. you have CA certs on the application that can verify the issuer of the received cert or A received cert's cert issuer i.e. itself. A lot of this depends on if you're rolling your own library or ...


0

Do all non-CA certs have to be End Entity certs? Yes. It's an either/or-thing according to RFC 5280, section 3.2: X.509 v3 also includes an extension that identifies the subject of a certificate as being either a CA or an end entity, reducing the reliance on out-of-band information demanded in PEM. This specification covers two classes of ...


0

Here your are trying to authenticate and trust both the networks while acting as bi- directional. The trusted authority certificate is different/same and CA issuing certificate may be different or the same it doesn't have any problem over on it. Note: Don't use self-signed certificates for SSL communications and follow the standard RFC rules. If you want ...


0

X.509 certificates are documents that are designed to hold information that is certified to be an exact, unchanged copy of critical security information. The certifier is usually a mutually trusted third party. That information consists of several important values, but right now you need to understand just a few: the name of the organization to whom the ...



Top 50 recent answers are included