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.
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 ...
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 ...
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. ...
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
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 ...
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 ...
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 ...
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 from ...
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 ...
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 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 Access-Control-Allow-Headers header does not support wildcards. You can only supply a list of actual headers that are allowed.
If you still want to allow all headers, you can make your web application look at which headers are present in the request and reflect all these in Access-Control-Allow-Headers.
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 ...
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 ...
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 ...
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 ...
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 ...
802.1x and Active Directory integrated authentication certificate requirements are outlined in the following document: Minimum client certificate requirements, specifically:
For computer certificates, the Subject Alternative Name (SubjectAltName) extension in the certificate must contain the fully qualified domain name (FQDN) of the client, which is also ...
I'd configure a reverse proxy with SSL decryption capabilities. Therefore the cert is put in a single server and it terminates the SSL/TLS connection.
Your private key will only be on one server and you'll also have the ability to inspect HTTP traffic using a IDS/IPS.
No, both those SQL databases do not.
The asterisk is used in statements to select all columns opposed to specifying particular columns.
It's usage is:
SELECT * FROM Accounts WHERE Email = 'email@example.com'
This would return the full table row(s) where the Email column is equal to firstname.lastname@example.org.
The closest to wildcards would be when using the LIKE ...
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.
If you purchase a certificate from a CA for a hostname like www.example.com (as the Common Name in the Subject field of the certificate), most CA's will also include the domain name example.com in the Subject Alternate Name field, so that the certificate will work for both www.example.com and example.com. But, that's usually the extent of it. If you want ...