I'm having a hard time adding my SSL cert on Parse.
I get this "App's custom domain name must match certificate CN" error. I've been following this https://www.digicert.com/csr-creation-ssl-installation-parse-php-sdk.htm#install_ssl_certificate tutorial even though i'm using javascript for my backend not PHP.
I get a checkmark (no errors) when I add my Host name so there's nothing wrong with that it would seem. I've created a .pem file with the entire SSL cert trust chain, tried uploading it but I get the same error. And just for the heck of it I also uploaded my Primary Cert without attaching intermediary or root certs which didn't work either.
I've created the CSR similar to what was shown in the example. Are there any other online help like a pay per session with a Parse developer? Because this is driving me crazy
In the Parse docs Https section it just says to upload your custom domain cert. I have my cert for my custom domain and I'm trying to upload it so why am I getting this error?
Related
I am trying to call some REST API toward the server authorises only certificates. I have set the certificates in Postman (.crt, .key and .pfx files and passphrase). But when I make a REST API call, I see Postman console logs that certificate files are included in the request but I get
Error: mac verify failure
I searched on internet and found some conversations suggesting this error is caused by wrong or missing passphrase, but I am sure I am providing correct passphrase (the one I set when converting pfx file to .crt file).
I am not sure if I should provide the passphrase I set while converting pfx file to crt file or somthing else?
Any help is highly appreciated.
Thanks
Please try to select only the CRT and Key files and leave PFX empty.
If you used a passphrease for generating the CRT File, you have to put it in the "passphrase" field. Otherwise leave "passphrase" blank.
If its still not working, please provide more informations.
I've got something weird going on with Firefox. I'm working on a web application which is hosted on multiple endpoints. I've created self signed certificates for those endpoints using Powershell, which are all signed by the same (also self signed) root CA.
In order to trust the certs I've tried a couple of things:
Exceptions in FF
Adding them to the cert store of Windows and setting 'security.enterprise_roots.enabled'
Creating a custom config using CCK2 and adding the root cert in there
When I browse the site using Firefox, the main URL works. But stuff that's being loaded from dynamically generated URLs (the why of this is not relevant) does not work. I'm getting SEC_ERROR_UNKNOWN_ISSUER error for those URLs. The only difference is that the main URL is a normal cert, the dynamically genated URL's are using a wildcard cert.
The cert chains are as follows:
Self Signed Root Cert
main.domain.com (works)
*.apps.domain.com (does not work)
So getting a page from main.domain.com works fine, no validation issues. Getting something from 1234.apps.domain.com does not work with a SEC_ERROR_UNKNOWN_ISSUER in return which I find very weird as it's the same issuer. Any ideas?
Im having issues with angular.io in my enterprise network caused by the certificate. Looking more in detail I noticed its been signed for *.firebaseapp.com. However it looks valid in my phone. Android screenshot
It doesnt make any sense, you cant have a valid ssl connection if the certificate was signed for another domain. Does anoyone understand whats happening with that certificate and why its look valid for my android browsers?
Thanks
If you look at the certificate details all look at the long list of Subject Alternative Names you will see that *.angular.io is covered under there. You can read more about those here.
Basically, it's just a list of hostnames that can used with one certificate.
.
The problem:
I have 2 websites that have the same IP address (a domain and a subdomain), and I have an SSL certificate for each of them. The domain is a word-press site while the sub domain is a ruby on rails application. the subdomain has the certificate installed and works with no problems, but when I try to add the second certificate for the main domain, it works, but it prevents access to the subdomain.
In the web browser inspection page it shows this error :
“XMLHttpRequest cannot load https://giladparking.com/wp-content/plugins/wp-slimstat/wp-slimstat-js.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://monthly.giladparking.com' is therefore not allowed access.”
What I have tried:
I have followed this tutorial to allow for SNI support and it seems to work except for the previously mentioned issue.
I have taken a look at this post as well which explains that you can't make XMLHTTPRequests across domains. but this issue only arises when both certificates are in effect.
“XMLHttpRequest cannot load https://giladparking.com/wp-content/plugins/wp-slimstat/wp-slimstat-js.php....
The certificate for this sites is valid for monthly.giladparking.com and www.monthly.giladparking.com but not for giladparking.com. That's why any access to this site will fail with a certificate error. This problem is not restricted to XMLHTTPRequests.
We use AWS CloudFront as our CDN in front of an Apache website running on an EC2 server. The website uses SSL (https) and CloudFront is configured to use the default CloudFront certificate, so our application loads static assets using https://xxxxxxcloudfront.net/path/to/asset, rather than https://ourdomain.com/path/to/asset.
Our SSL certificate, issues by Go Daddy, expired yesterday. After installing a new certificate on the web server, CloudFront no longer seems able to deliver any assets. It is simply returning a 502 error with the message CloudFront wasn't able to connect to the origin.
The Apache logs don't seem to indicate any problems with the new certificate, when I visit the site I can see the little green lock icon and I no longer see any warnings about an invalid certificate. Further, if I try to load the assets directly from our webserver, using https://ourdomain.com/path/to/asset, instead of the CloudFront URL, the assets seem to load without any problems.
I don't recall doing anything with CloudFront the last time we replaced a certificate. Is there something that needs to be updated in CloudFront when the webserver's SSL certificate gets updated? Any tips on what to look for?
I was able to resolve this issue!
After installing the certificates provided by Go Daddy there was an issue with the intermediate chain. The certificate chain file Go Daddy provides by default includes the root. CloudFront sees that as a problem and will not connect to the origin. I downloaded and installed the certificate chain without the root and everything started working again.
Thanks to #error2007s and #michael-sqlbot for their help!