We procured standard ssl certificate to mydomain.net from godadday.
We shutdown live server mydomain.com, configured new server mydomain.net with ssl, everything works fine.
We have added redirect records in DNS for mydomain.com to mydomain.net
www.mydomain.com redirecting properly to www.mydomain.net
We are experiencing a issue, when any request to https //www.mydomain.com
redirection happening but with untrusted certificate error message.
www.mydomain.com uses an invalid certificate.
The certificate is valid for the following names:
www.mydomain.net , mydomain.net
(Error code: ssl_error_bad_cert_domain)
Godaddy india support not able to resolve the issue, escalated to US support no update from US support.
Please suggest me how to resolve this issue?
Thanks,
ItsR
Redirection inside a HTTPS connection from domain A to domain B needs a proper certificate for domain A too, which does not seem to be in your case. This is because the redirection happens inside the TLS connection, i.e. the TLS connection needs to be established first which needs the proper certificate.
Related
I'm trying to do this:
https://dummiesite.com --> http://dummiesite.com
and
http://dummiesite.com --> http://new.dummiesite.com
and
http://new.dummiesite.com --> https://new.dummiesite.com
So no matter what site the user goes, it will allways be redirected to https://new.dummiesite.com
The problem:
With I have a wildcard certificate for *.site.com. But it is only valid for all the subdomains of site.com, not for site.com itself. With lighttpd I cannot use more than one certificate per IP (I have only one), so when the user goes to https://dummiesite.com, it gets an error because the certificate is not valid.
That is why I'm trying to redirect https://dummiesite.com to http://dummiesite.com. How can I do it without a valid certificate and without showing the user errors?
Thanks for your help
You can't with the current certificate. HTTPS is HTTP inside an SSL tunnel, so before you can do the redirect at the HTTP level the SSL connection has to be established. But this fails because your certificate does not match the hostname. You need to get a certificate which includes both *.dummiesite.com and dummiesite.com (yes, this is possible).
If a website is being redirected, does the original domain name need to have an SSL certificate, or the redirected domain name or both?
Both, because the redirection is an HTTP-level thing which happens inside the SSL envelope. The client needs to establish an SSL connection to the original host name before it sees the redirect, then after following the redirect it must establish another SSL connection to the target host name.
If you're redirecting between the www and non-www forms of the same domain, it's often the case that one certificate will cover both (using the "subject alternative name" mechanism). For example, I have a site with a certificate from RapidSSL, and when you ask them for a certificate securing www.example.com they automatically issue it with a SAN for the plain example.com form included. I have a single Apache HTTPD with two name-based virtual host definitions on the same IP address pointing to the same certificate.
Recently, the company I work for changed their name, and therefore is changing its domain name. Previously, we redirected all requests on port 80 of our web server to https : //www .olddomain.com, so that all pages were sent over SSL. Now that we have changed, our SSL certificate for www. olddomain.com has expired, and we want to redirect all requests for https : //www. olddomain.com to https : //www. newdomain.com (in case anyone bookmarked us as https : //.....).
I have tried every redirection method I know, mod_rewrite, DNS forwarding, etc, but I cannot get https : //www.olddomain.com to redirect to https : //www.newdomain.com, it says that the site is untrusted.
We are running Apache 2.2 on linux.
Any help would be appreciated.
Thanks!
Not to dive into unnecessary details - if certificate itself has expired, you won't be able to make trusted connection with it, browser will always warn. To make it transparent, you'd have to renew/buy valid certificate for old domain, or force any possible website user to first download, install and trust your own RootCA certificate (obviously impossible). Theoretically there are some browser-supported HTTPS protocol extensions to deal with original construction of https, but even if they were implemented it still won't "help" for outdated certificate. It is problem with certificate itself, not really with virtual server hostname / certificate common name recognition and matching for which such protocol extensions are conceptually planned/designed.
You should have been performing domain migration during time when old certificate was still valid. Have a look here CNAME SSL certificates as well.
In order to secure my Rest Services, I have enabled SSL in IIS and Created a Self-Signed Certificate and assigned it to the HTTPS binding in IIS. I exported the same as pfx file and added the same in IE also but when I try to access the Services, I get the following error on Windows 7, Enterprise edition
HTTP Error 403.7 - Forbidden
The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
And on Windows Server 2003, this is
HTTP Error 403.7 - Forbidden: SSL client certificate is required.
Internet Information Services (IIS)
I am not sure what shall I do except adding the certificate in IE under “Personal” and “Trusted Root Certification Authorities”? Could you please suggest me some step, in order to make this work.
Note: I have tried with “Self-Signed Certificates” as well as with Certificates generated from Microsoft “Certificate Services” also.
Any help is greatly appreciated.
SSL is used to verify the identity of the server, not the identity of the client. The error suggests (http://support.microsoft.com/kb/199215, "This is used for authenticating you as a valid user of the resource. ") the server wants to identify the client. Which of the two are you trying to do?
Edit: SSL requires the public part of the SSL certificate to be available to the client. Adding it to the trusted root certificates seems to me to be the only way to make the public part of a self-signed certificate available to the browser.
I am trying to consume a HTTPS based SOAP WebService via ColdFusion, but it is returning "Connection Failure".
On dumping the result variable, it showed:
Error Detail: "I/O Exception: Name in certificate 'subdomain1.domain.com' does not match host name 'subdomain2.domain.com'"
I can ignore such warning if I browse the HTTPS wsdl in browser, But the Question is; How can I bypass this warning using <CFHTTP>?
Thanks
Better solution is to have the host of the service. Get a proper SSL certificate for that subdomain or a wildcard certificate that will allow them to have as many subdomains as needed with a single certificate.
I have been looking for a solution to this as well (a well-known payment gateway provider has an SSL issue on their server I have to work around). One solution I came up with was to put an entry into the server's hosts file and set it to the IP address of the hostname the SSL certificate was using. Fortunately their web server just accepts connections based on IP rather than hostname, so I was able to fool my server into thinking that I was connecting to the "proper" hostname published in the SSL cert and override the IP for that hostname in the public DNS. A way to tell Java that the name mismatch is "okay" would be nice though.