'Bad Request This combination of host and port requires TLS.' issue calling springboot app running as azure container app

Question

'Bad Request This combination of host and port requires TLS.' issue calling springboot app running as azure container app

Chandrashekar, Anil (Cognizant) 40

Hi

Im facing 'Bad Request This combination of host and port requires TLS.' issue calling a springboot application deployed as azure container app. This springboot application is running on https and ssl enabled.

The container app has ingress enabled. Im using container app url(https) Ito hit the end point hosted on the springboot application. Looks like though the springboot app runs on https, calls to container app are routed as http resulting in TLS error.

Ex container endpoint;- https://abcservicecnt.bforest-xyz.westus3.azurecontainerapps.io/my-end-point

Any help would be appreciated. Thanks.

Shireesha Eeraboina 3,435 Reputation points Microsoft External Staff Moderator

2025-03-12T07:58:52.32+00:00
Hi Chandrashekar, Anil (Cognizant),

Thanks for reaching out.

The error arises because the ingress of Azure Container Apps is forwarding HTTP traffic to your Spring Boot application, which expects HTTPS. To resolve this:

Disable Insecure Traffic:

Set allowInsecure: false in your Container App’s ingress configuration to enforce HTTPS-only traffic. Here’s an example for Bicep:

ingress: { allowInsecure: false }

Verify TLS Termination:

Ensure that TLS is terminated at the ingress level. If your Spring Boot application still requires HTTPS internally, consider disabling it since the ingress already manages TLS.

Check Certificate Configuration:

If you are using a custom domain, bind a TLS certificate to the Container App through the Azure Portal or CLI. For default domains, Azure automatically provides TLS.

For your reference, please review the following documentations for further clarification:

Troubleshoot a container app

Client traffic to the application

If issues continue, verify the server port and SSL settings of your Spring Boot application to ensure it accepts HTTP if the ingress is handling TLS.

If you have any further queries, please let us know we are glad to help you.
Chandrashekar, Anil (Cognizant) 40 Reputation points

2025-03-12T20:05:16.9+00:00

Thanks Shireesha for your response.

We have already set 'allowInsecure: false' and it is not solving the issue for us. Also, since our microservices are running on https, it will only accept https traffic, how do we ensure https traffic reaches our microservice without TLS termination at Ingress?

The reason why we need only the https traffic on our microservices to avoid potential security threats that come with http traffic, if at all microservices serve http.

Thanks in advance.
Shireesha Eeraboina 3,435 Reputation points Microsoft External Staff Moderator

2025-03-17T07:12:06.72+00:00
Hi Chandrashekar, Anil (Cognizant),

To make sure HTTPS traffic goes directly to your Spring Boot microservices without TLS termination at the ingress, you can enable ingress-to-app TLS. This allows secure communication from the ingress controller to your application. You can do this with the following command:

az spring app update --enable-ingress-to-app-tls -n app_name -s service_name -g resource_group_name

This setup will keep the traffic as HTTPS throughout the entire communication path, ensuring your security needs are met.

If you have any further queries, please let us know we are glad to help you.
Shireesha Eeraboina 3,435 Reputation points Microsoft External Staff Moderator

2025-03-18T05:41:52.4166667+00:00

Hi Chandrashekar, Anil (Cognizant),

Following up to see if the above information was helpful. If you have any further queries, do let us know.
Chandrashekar, Anil (Cognizant) 40 Reputation points

2025-03-19T00:31:38.37+00:00

Hi Sireesha, Thank you for your input.

We used similar(below) approach to get the TLS termination disabled at the ingress. Now the https calls are reacing our container(microservice).

az containerapp show -g some-rg -n someapp -o yaml > app.yaml

Then, update the relevant .yaml section - and then update the application with the updated .yaml:

targetPortHttpScheme: https

az containerapp update -n someapp -g some-rg --yaml app.yaml

However, after this call reaches container1 and then this container calls container2, we get below SSL issue. Both container1 and container2 are running on https and uses self signed certificates.

Caused by: javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP address ... found 2025-03-16T20:01:17.0936423Z stdout F at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) 2025-03-16T20:01:17.0936445Z stdout F at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) 2025-03-16T20:01:17.0936570Z stdout F at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) 2025-03-16T20:01:17.0936598Z stdout F at java.base/sun.security.ssl.TransportContext.fa

Let me know if you have any comments/suggestions.
Shireesha Eeraboina 3,435 Reputation points Microsoft External Staff Moderator

2025-03-20T04:48:46.57+00:00

Hello Chandrashekar, Anil (Cognizant),

Following up to see if you have a chance to check my previous response and helped do let me know if you have any further questions on this.

Accepted answer

0 additional answers

Your answer

Shireesha Eeraboina 3,435 Reputation points Microsoft External Staff Moderator

2025-03-12T07:58:52.32+00:00

Hi Chandrashekar, Anil (Cognizant),

Thanks for reaching out.

The error arises because the ingress of Azure Container Apps is forwarding HTTP traffic to your Spring Boot application, which expects HTTPS. To resolve this:

Disable Insecure Traffic:

Set allowInsecure: false in your Container App’s ingress configuration to enforce HTTPS-only traffic. Here’s an example for Bicep:

ingress: { allowInsecure: false }

Verify TLS Termination:

Ensure that TLS is terminated at the ingress level. If your Spring Boot application still requires HTTPS internally, consider disabling it since the ingress already manages TLS.

Check Certificate Configuration:

If you are using a custom domain, bind a TLS certificate to the Container App through the Azure Portal or CLI. For default domains, Azure automatically provides TLS.

For your reference, please review the following documentations for further clarification:

Troubleshoot a container app

Client traffic to the application

If issues continue, verify the server port and SSL settings of your Spring Boot application to ensure it accepts HTTP if the ingress is handling TLS.

If you have any further queries, please let us know we are glad to help you.
Chandrashekar, Anil (Cognizant) 40 Reputation points

2025-03-12T20:05:16.9+00:00

Thanks Shireesha for your response.

We have already set 'allowInsecure: false' and it is not solving the issue for us. Also, since our microservices are running on https, it will only accept https traffic, how do we ensure https traffic reaches our microservice without TLS termination at Ingress?

The reason why we need only the https traffic on our microservices to avoid potential security threats that come with http traffic, if at all microservices serve http.

Thanks in advance.
Shireesha Eeraboina 3,435 Reputation points Microsoft External Staff Moderator

2025-03-17T07:12:06.72+00:00

Hi Chandrashekar, Anil (Cognizant),

To make sure HTTPS traffic goes directly to your Spring Boot microservices without TLS termination at the ingress, you can enable ingress-to-app TLS. This allows secure communication from the ingress controller to your application. You can do this with the following command:

az spring app update --enable-ingress-to-app-tls -n app_name -s service_name -g resource_group_name

This setup will keep the traffic as HTTPS throughout the entire communication path, ensuring your security needs are met.

If you have any further queries, please let us know we are glad to help you.
Shireesha Eeraboina 3,435 Reputation points Microsoft External Staff Moderator

2025-03-18T05:41:52.4166667+00:00

Hi Chandrashekar, Anil (Cognizant),

Following up to see if the above information was helpful. If you have any further queries, do let us know.
Chandrashekar, Anil (Cognizant) 40 Reputation points

2025-03-19T00:31:38.37+00:00

Hi Sireesha, Thank you for your input.

We used similar(below) approach to get the TLS termination disabled at the ingress. Now the https calls are reacing our container(microservice).

az containerapp show -g some-rg -n someapp -o yaml > app.yaml

Then, update the relevant .yaml section - and then update the application with the updated .yaml:

targetPortHttpScheme: https

az containerapp update -n someapp -g some-rg --yaml app.yaml

However, after this call reaches container1 and then this container calls container2, we get below SSL issue. Both container1 and container2 are running on https and uses self signed certificates.

Caused by: javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP address ... found 2025-03-16T20:01:17.0936423Z stdout F at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) 2025-03-16T20:01:17.0936445Z stdout F at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) 2025-03-16T20:01:17.0936570Z stdout F at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) 2025-03-16T20:01:17.0936598Z stdout F at java.base/sun.security.ssl.TransportContext.fa

Let me know if you have any comments/suggestions.
Shireesha Eeraboina 3,435 Reputation points Microsoft External Staff Moderator

2025-03-20T04:48:46.57+00:00

Hello Chandrashekar, Anil (Cognizant),

Following up to see if you have a chance to check my previous response and helped do let me know if you have any further questions on this.

Answer 1

Shireesha Eeraboina 3,435 Microsoft External Staff Moderator

Hello Chandrashekar, Anil (Cognizant),

To resolve the SSL handshake issue between your containers, ensure that the self-signed certificates for both container1 and container2 have the correct Subject Alternative Names (SANs). The error indicates that the IP address being used is not listed as a SAN in the certificate.

You can address this by:

Updating your self-signed certificates to include the IP addresses of the containers as SANs.
Using DNS names instead of IP addresses for communication between the containers, and ensuring the certificates include those DNS names as SANs.

I hope this answers your query! Let me know if you require any additional help or clarification.

This should help prevent the SSL handshake errors you are encountering.

Shireesha Eeraboina 3,435 Reputation points Microsoft External Staff Moderator

2025-03-21T03:40:19.3733333+00:00

Hi Chandrashekar, Anil (Cognizant),

If you found the response helpful, please click Accept Answer and Yes for the provided answer. This will help other community members with similar issues find the solution more easily.

Share via

'Bad Request This combination of host and port requires TLS.' issue calling springboot app running as azure container app

0 additional answers

Your answer