I have a multi-master Origin setup in AWS. I have an ELB in front that uses SSL certificate configuration.
I'm having difficulty configuring the access to the Web console as it seems that the web sockets are being interrupted. I can tell this because of the image below and the inability to access the logs or terminal for a pod in the web console.
Server connection interrupted
What is the proper configuration in AWS to allow the web console to function correctly?
I resolved my issue. I figured out the ELB configuration by following the CloudFormation template in the reference architecture here:
https://github.com/openshift/openshift-ansible-contrib/reference-architecture/aws-ansible/playbooks/roles/cloudformation-infra/files/greenfield.json
I also had an issue with the version of Chrome (50) and had to upgrade to version 55. Basically I was getting 'ERR_DISALLOWED_URL_SCHEME'. This post pointed my towards upgrading Chrome:
https://productforums.google.com/forum/#!topic/chrome/leVmLPNVISI
Related
We are using Spartacus Version 3.0.0 and have setup Cloud Deployment via SAP CCV2 Cloud.
We followed the steps to enable SSR described in https://sap.github.io/spartacus-docs/server-side-rendering-in-spartacus/#adding-ssr-support-using-schematics-recommended. Additionally we also followed the guide for the workaround needed regarding the file structure in CCV2 cloud: https://sap.github.io/spartacus-docs/ssr-ccv2-issue-spartacus-version-2/#page-title
So far, all works locally when starting the server both in dev and production mode. As soon as we deploy into the CCV2 Cloud, we don't have Server Side rendering at all anymore.
In the Kibana log, we sometimes see the error message "SSR Rendering exceeded timeout, fallbacking to CSR", but only for some requests occasionally, which means, that for most requests, there is no SSR, but also no error logs..
Any idea?
The problem was caused by the IP Restriction on the DEV environment of CCV2. This IP Restriction is currently also being applied for the request coming from the Storefront Service during an SSR Request, as the ip of the storefront service was not whitelisted, the call always returned a 403, what was returning as a SSR timeout.
The spartacus documentation has been update regarding that problem: https://sap.github.io/spartacus-docs/server-side-rendering-optimization/#troubleshooting-a-storefront-that-is-not-running-in-ssr-mode
We have created an SAP Bug ticket to fix that problem.
I basically follow the steps in this question to create SSL certificates for ActiveMQ. Now with some help, I can connect my C# application to ActiveMQ. However when I tried to connect my Angular application to it, I got ERR_CERT_COMMON_NAME_INVALID error.
I actually have an ActiveMQ instance running in AmazonMQ and it works fine with my Angular application. So I think this is the issue of the certificate when I try to run the ActiveMQ in my own docker image.
For some details, I am using a domain name dev.com pointing to 127.0.0.1, which is set in host file. I am using dev.com to access both C# application and Angular application so I plan to use wss://dev.com:61619 to access ActiveMQ from my Angular application. When I generate keystore, I specify dev.com as the CN. In addition, I have another self-signed certificate generated with OpenSSL for Angular and C# application, not sure if there will be any conflict between them.
Can anyone please help to see what could be wrong?
Thank you
I enabled HTTPS for my APIs using local generated SSL key following the instructions in Enable HTTPS in Spring Boot. The ssl settings are included in application.properties:
server.port=9443
server.ssl.key-store=classpath:server-keystore.jks
server.ssl.key-store-password=123456
server.ssl.keyAlias=server-keypair
server.ssl.key-store-type=JKS
It works with https when tested locally. Then I packaged it as a Jar and deployed on Amazon Beanstalk environment. When I hit endpoint https://eb-env-url:9443/endpoint/, it timed out without any specific error. The Beanstalk log does not show any request was made through to the server at all.
I read it somewhere that personal key may not work when deployed to cloud, but it should at least give me some security error that points to that direction. I suspect this may have to do with the environment configuration. I used to do HTTP only for the environment and did not make any changes to the config after switching to HTTPS. One of the environment variable is SERVER_PORT which is set to 5000. I am not sure if some changes need to made in the Beanstalk environment in order to make HTTPS work.
I have a client site set up on AWS with multiple servers running HTPPS behind an Elastic Load Balancer. At some point, someone from the client's team attempted to update the SSL Cert by installing a new one directly on one of the servers (instead of in the ELB).
I was able to upload a new cert to the ELB, but when traffic is directed towards the server with the improperly installed cert, it triggers a security warning.
No one can seem to answer who attempted this install, how they went about, or where they installed it.
What's the best way to go about finding and removing it?
Thanks,
ty
If it's installed on the server, it has very little to do with AWS. I see you tagged the question with apache so I assume the server is running Apache Web Server. You will have to connect into that server and remove the SSL settings from the Apache Web Server configuration, just like you would with an Apache Web Server install anywhere else.
Is it possible to deploy a node.js app on Cloud Foundry that listens for HTTPS requests on port 443?
I can find various references to SSL support in the Cloud Foundry forums, but no actual examples of HTTPS apps. The article "Setup SSL on cloudfoundry landscape" seems to indicate that I need to install nginx and use that, but there is not really enough information there to tell me what I need to do.
The SSL connection will terminate at the loadbalancer and then forward the unencrypted HTTP connection to your node app.
Just use https://your-app.cloudfoundry.com instead of http://...
You don't need nginx in particular, but you do need something capable of listening to a port (which Cloud Foundry will assign at the moment, indicated by the environment variable PORT or, for older versions of Cloud Foundry, VCAP_APP_PORT). So nginx will work for this purpose, but if you have made a node.js app, the core module http (optionally paired with express) would be a more natural choice of webserver.
Now if your app requires ssl, you'd think that you'd need to configure your webserver (nginx, express, etc.) for HTTPS, but you do not need to do so because Cloud Foundry handles the SSL and passes the decrypted HTTP to your webserver.
So if you are using node.js core modules, use the http, not https module.