I think you should segregate your environment. Only production certificates should be trusted on all your network. Dev and testing certificates should only be trusted on the computers where developers work.
In a more secure environment you would not even use the same root CA for production and development environments.
Please try this Chrome hack: when browser shows the page with the invalid certificate message, type in your keyboard the word "proceed" and then hit Enter.
You should be able to proceed to the requested page.
On newer versions of Chrome, you may have to type "danger" and hit Enter instead.
There are two distinct things here. One is about the number of hostnames that you can put in a certificate. The other is the notion of "wildcard names".
In the Subject Alt Names extension, you can put "alternate names" of type dNSName. Each of them is an "acceptable server name" (i.e. clients will accept the certificate for a server that purportedly uses ...
This is a feature called HTTP Strict Transport Security - see http://dev.chromium.org/sts and http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security.
Sites that send the Strict-Transport-Security header (or are preloaded in Chrome, such as apis.google.com) cannot be accessed when the server SSL cert is invalid.
The certificate sent for chart.apis....
I'll supplement @schoeder's answer with some technical details.
My understanding of your situation is that you have servers applications like this:
and your partner also has some applications running on the same server:
All of the above are ...
As a result of an announcement by Let's Encrypt, the information in this answer is now of historical value only. See the information in Emil Stenström's answer.
The IETF-standardized ACME v2 protocol will be available soon, and Let's Encrypt announced on 14 June, 2017 that they will have a new API endpoint against that standard in Jan. 2018. As reported by ...
Insider threats are a major problem that not enough organizations think about. The IT person is correct to bring this up.
But the argument is just one factor. A 'threat' has been raised, and now a 'threat analysis' needs to be performed. What is the impact if a malicious insider (outsourced or not) can impersonate services? If this impact is low, then you ...
Let's Encrypt just announced that they will offer wildcard certificates in 2018:
Wildcard certificates will be offered free of charge via our upcoming ACME v2 API endpoint. We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time. We encourage people to ask any ...
A wildcard certificate matches a pattern, not a hostname or set of hostnames. It's issues to *.example.com, meaning any host of format [subdomain].example.com will match. It is notable perhaps, that it is limited to a single level so the *.example.com wildcard cert could be used for sub1.example.com and sub2.example.com, but not deeper.sub1.example.com. ...
A certificate is only as good as whoever validates it thinks it is. A certificate is good for SSL as long as the SSL clients (e.g. Web browsers, or VPN clients) accept it as good. Whatever you do, the existing clients will lead the dance.
A "wildcard" certificate is described in RFC 2818, section 3.1:
Names may contain the wildcard
character * which ...
Your certificate will have certain properties, I believe they are called 'certificate usage' or similar. If, under there, you find Certificate Signing, then yes - you can use your certificate to sign other certificates.
Note: the constraint Signing alone does not mean you can sign other certificates, it must be the full Certificate Signing.
Your wildcard ...
This document can give you an historic overview of how standardisation for CAs has evolved.
A fragment of the document that gives a well overview:
The first requirement imposed specifically on CAs as a group was in
2000 when an annual security audit under the WebTrust for CAs
standards was mandated by browsers and others with trusted root
It is not a matter of wildcards. The behaviour you observe is due to the following: if there is a Subject Alt Name extension in the certificate, then the Common Name part of the DN is simply ignored. Said otherwise, the server names in the certificate should always be in a Subject Alt Name extension; the Common Name part of the subject DN is used as a ...
This boils down to subdomain enumeration:
Say you have a wildcard DNS entry and the attacker tries the following subdomains:
If you have a wildcard DNS entry then the following results will be returned.
admin.example.com - Exists
cms.example.com - Exists
email.example.com - Exists
ssh.example.com - Exists
rdp.example.com - ...
Based on the context you've provided I don't see a significant threat.
I'm assuming you're running a pretty typical internet facing web service and from that perspective the explanation your security researcher provided seems a bit muddled.
The most common i can think of is phishing. Wildcard DNS is a handy
feature, and phishers are apparently using it ...
If * appears to be a wildcard, it could be LDAP, probably a query to Windows ActiveDirectory.
The good thing in AD is that the LDAP structure is known, so you can get an idea how to bypass authentication. This for example is a reference for the attributes of a user in AD. It could of course be a custom LDAP structure too.
OWASP has a few ideas for LDAP ...
I'm going to assume that your developers need locally trusted SSL certificates. As pointed out previously, it might be worth considering if they really do need those in the first place.
A wildcard certificate refers to a certificate with a CN or SAN on the form *.something.example.com.
The * expands to only a single label; it does not expand to multiple ...
According to GlobalSign, the following browsers support ECC:
Browser Minimum Version Required
Apple Safari 4 (On ECC Compatible OS)
Google Chrome 1.0 (On ECC Compatible OS)
Microsoft Internet Explorer 7 (On ECC Compatible OS)
Mozilla Firefox 2.0
Supported operating systems ...
This error message triggered by a feature of the web called "HTTP Strict Transport Security" which allows website operators to tell browsers that their site must only be contacted over a secure HTTPS connection. This feature is specified in RFC 6797. In particular, you may want to read section 12.1, which says:
No User Recourse
Failing secure ...
The Server Name Indication extension, now implemented by most SSL libraries, implies that a sniffer would see the name api2.server2.com as part of the unencrypted ClientHello message from server1.
As for the rest of the URL (the path on server2), it is sent only after the handshake, so it is not visible to sniffers (but sniffers may still obtain a good ...
It is not a good idea to have a public DNS record which points to a non-public IP address. This can be used to circumvent same origin policies by exploiting issues on internal systems. For more details see http://www.securityfocus.com/archive/1/486606, where a vulnerability in CUPS on localhost was exploited this way.
Probably easier and definitly safer ...
If the thieves man-in-the-middle connections to saas.example.com and present the wildcard cert, would the customer getting man-in-the-middled get any sort of SSL-related warning from their browser?
Usually not because the attacker presents a non-revoked certificate which is valid for the accessed host. The client would only reject the valid certificate if ...
Clients wouldn't know that there's two certificates for the same domain issued by two different CA's and throw a warning flag?
They would just see whichever certificate is currently 'active' on the server and as long as it's valid, it should be used?
CAs do not typically publicize their clients and certificates, or share ...
You are describing a situation in which you have two separate, valid wildcard certificates signed by separate CAs. Unlike what the current title claims it is not the "same wildcard cert".
There is nothing that stops you from having multiple certificates for the same domain(s).
Clients will verify the validity and trust of the certificate presented by your ...
Certificates are now free! And everyone should use them.
Because of "services" like Let's Encrypt (and possibly others in the future)
You can create as many certificates for single domains as you want, but also wildcards certificates where implemented march 13th 2018, according to their own upcoming features page.
Wildcard certificates are not much costly as you think, I bought wildcard certificate at $42 for one year, which I think it is affordable. https://www.ssl2buy.com/wildcard-ssl-certificate
There is difference between single and wildcard certificate because a standard certificate can secure only your single website and wildcard certificate can secure ...
There is no reason you can not use both certificates.
However take note that a wildcard certificate is only valid for a single leaf (so something.example.com and not invalid.something.example.com)
the 2 certificates are completely independent of each other.
It is even possible (although that would break CA guidelines) to issue multiple certificates for ...
I thought about the possibility that sticking a NUL byte (\0) to the path would cause glob() to ignore the part after the NUL. That's exactly how C strings work and filenames are passed to e.g. system calls as C strings.
But that doesn't seem to happen: on my system (Debian's PHP 7.0.27), both glob() and unlink() demand a string without NUL bytes, and error ...
RFC6125 section 7.2 strongly discourages the use of wildcards inside an IDNA part of the domain name:
o There is no specification that defines how the wildcard character
may be embedded within the A-labels or U-labels [IDNA-DEFS] of an
internationalized domain name [IDNA-PROTO]; as a result,
implementations are strongly discouraged ...