When testing under Android P, found a problem with the certificate. The UE was giving an error for the hostname resolution.
As per Adroid P:
RFC 2818 describes two methods to match a domain name against a certificate - using the available names within the subjectAlternativeName extension, or, in the absence of a SAN extension, falling back to the commonName.
The fallback to the commonName was deprecated in RFC 2818 (published in 2000), but support still remains in a number of TLS clients, often incorrectly.
the existing .cer has:
DirName:/C=DE/ST=xxx/L=xxx 81673/O=my company wireless products /OU=Test/CN=prod.comp.com/emailAddress=xxx#comp.com
How to add subjectAlternativeName configured to the existing cerficate?
Certificate is digitally signed and tamper-evident. If you modify any bit of the certificate, the signature will be broken and certificate will become invalid.
The only way to get new values there is to acquire new certificate by using same procedures used to get current certificate.
Related
I have created an API endpoint, I have a user of that endpoint requesting from servers at stackoverflow.com. I want to verify that the request was made from stackoverflow.com servers. One way I could verify it came from stackoverflow.com is to ask the developer to sign the request with their let's encrypt domain private key. I can then use their public key to decrypt the message.
I'm not totally sure I can decrypt the privately encrypted message with their public key but even if I could, I would like to avoid having the developer do any special type of encryption. Could I use TLS to verify the origin domain?
TLS supports client authentication, also called '2-way' or 'mutual' authentication. (SSL3 also did, but you should not be using SSL3.) See e.g. TLS1.2
'updated' for ECC and TLS1.3.
How to use this depends on the software (typically library or middleware) being used for TLS, which you didn't indicate; it is even possible some TLS stack doesn't support it at all, though I've never heard of any. Some stacks or use-cases allow client auth to be invoked without any code change, and others with only minimal or localized code change.
Some details that may or may not matter:
this does not sign the request. It authenticates the TLS connection (to be exact, it normally signs a transcript of the handshake) and then the data transferred over the connection is MACed (as well as encrypted) using keys created (and thus authenticated) by the handshake. This provides authentication but not nonrepudiation for the data; you the receiver can reliably determine it came from the sender, but you can't reliably prove this to a third party. For the closely related case of 'proving' the server, see the numerous crossdupes linked at https://security.stackexchange.com/questions/205074/is-it-possible-to-save-a-verifiable-log-of-a-tls-session .
this authenticates the data was sent by the identified client; it says nothing about the origin which as Sam Jason points out is often different.
the client is not necessarily identified by a domain name; it can be a person, organization, or something else. However, many CAs issue a single cert for both TLS server auth and client auth (look at the ExtendedKeyUsage extension in your own or any sample cert(s) to see) and in that case with few exceptions the subject is identified by a domain name or name(s) or at least wildcard(s).
I'm pretty sure you should be using some sort of API key or maybe something similar to how twilio signs its requests
one reason for these patterns is that it's common for HTTP requests to be proxied, with static requests handled by something other than the code/application server. therefore the TLS connection would have been terminated at the proxy server, and the actual application code wouldn't be able to easily see anything about the TLS connection used by the remote server
I've recently found something that questions everything I thought I knew about TLS.
This website https://int.lyve-lyon.alpha.grandlyon.com is secured with TLS but the certificate is actually issued to rec.lyve-lyon.alpha.grandlyon.com.
How can the server submit a certificate issued for a different host, and how can the browser not throw a TLS error? It looks like the certificate behaves like a wildcard one and I cannot understand why.
Subject Alternative Name (SAN) is an extension to X.509 that allows
various values to be associated with a security certificate using a
subjectAltName field. These values are called Subject Alternative
Names (SANs). Names include:
Email addresses
IP addresses
URIs
DNS names (this is usually also provided as the Common Name RDN within the Subject field of the main certificate.)
directory names (alternative Distinguished Names to that given in the Subject)
other names, given as a General Name: a registered[3] object identifier followed by a value
from https://en.wikipedia.org/wiki/Subject_Alternative_Name
I am having Postfix server configured for domain. From last few days my mails are marking as spam in gmail. I have already configured DKIM,SPF and DMARC for this domain. I have checked mail source and getting
"Authentication-Results: mydomain; dmarc=fail header.from=mydomain"
I have checked all the support docs but didn`t find anything.
Could you provide full sample headers or run a classification test with a third party?
Often, the TXT records aren't correctly created with the proper name style or have a syntax error causing the mail server parser to fail. Since DMARC fails the issue can be in either SPF or DKIM. In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.
Generally speaking, its really hard to help without proper details. Kindly always provide DNS and configuration samples.
My IIS site is giving browsers problems. They pop up a security warning that the security certificate does not match the name of the site. I'm using a self-signed certificate for testing. I view the certificate. It has the name.
DnsName.mydomain.com
but the browser is using
MachineName.mydomain.com
There is a CNAME entry pointing DnsName.mydomain.com to MachineName.mydomain.com.
Even so, they are obviously different. Can you tell me how I can get a new self-signed certificate with the name MachineName.mydomain.com, and how to install it on my test web server such that browsers can use either name without getting this security warning?
I can have the browser install any certificate a self-signed cert from my web server, that's not the problem. The problem is the warning. Here's a screen shot of what I mean.
You can only have one cert per site.
There are a couple of heavy-handed ways of getting around this:
Completely duplicate your site and have a cert on each
Use SSL-Acceleration and have two different external IPs on a load balancer that both point to the same internal.
There's also one easy way since you're already self-signing: Just wildcard it (*.mydomain.com). Generating this on a Windows box is explained here and Generating this on a Linux box is explained here.
If you really don't want to do that, I'd just have a forced redirect from one URL to the other instead of a CNAME alias.
I have the following requirement to map many domains to a single site instance for my web application, and I'm wondering if this is solvable using a single SSL wildcard certificate in IIS 7, or whether I need two wildcard cerfiticates. Here's my current plan:
Certificate #1 - *.mydomain.com
https://customer1.mydomain.com
https://customer2.mydomain.com
https://customer2.mydomain.com
etc...
Certificate #2 - admin.*.mydomain.com
https://admin.customer1.mydomain.com
https://admin.customer2.mydomain.com
https://admin.customer3.mydomain.com
etc...
My intentions are the following:
A single IP address that all of the above domains map to.
Can this be accomplished without the second certificate? I was told that I must have two by both Thawte and Godaddy.
The website is really the same site instance for all clients, but a different color scheme and logos will be displayed based on the URL. (hence multiple domain names)
I do not want to have to replace the certificate each time I add a new customer, hence the wildcard certificate.
I want to automatically redirect any request that comes in as http:// or blank to any of the above URLs to its https:// counterpart. For example, http://customer1.mydomain.com would automatically redirect the user to https://customer1.mydomain.com. I am currently doing this with a regular certificate, but since we're growing, I want to switch to wildcard. Is this still possible with the URL Rewrite IIS Snap-In?
I'm curious if anything I'm doing here is bad practice or if there is a better approach.
Thanks
In your example, certificate #2 isn't possible. However, certificate #1 is. To use a single wildcard, you might be better off using certificate #1, and then using customer1.mydomain.com/admin for the admin portion. Or admin.mydomain.com/customer1. Then you could configure your DNS, http redirects, and context switching to get the client to right portion of your app from the admin.customer1.mydomain.com.
Another option would be to use names like customer1.mydomain.com and customer1admin.mydomain.com. That would all fall under your certificate #1 wildcard and get a similar outcome to your plan perhaps.
As of this posting, this is not possible with a wildcard certificate.