On Junos OS Evolved 24.4R2-S3.7-EVO, enabling gRPC SSL request-response under system services extension-service can cause nginx to fail after commit.

After the configuration is committed, the router raises the alarm:

Application nginx fail on node Re0

This issue is deterministic. When request-response grpc ssl is enabled, nginx fails to start. When the service is disabled, the alarm clears.

To reproduce the issue:

1. Copy root_ca.crt and intermediate_ca.crt to /var/tmp/ on the router.
2. Load the CA certificates with the following commands:

request security pki ca-certificate load ca-profile BRD_CA filename "/var/tmp/root_ca.crt"
request security pki ca-certificate load ca-profile BRD_CA_INT filename "/var/tmp/intermediate_ca.crt"

3. Apply the following configuration:

set security pki ca-profile BRD_CA ca-identity "Test Root CA"
set security pki ca-profile BRD_CA revocation-check disable
set security pki ca-profile BRD_CA_INT ca-identity "Test Intermediate CA"
set security pki ca-profile BRD_CA_INT revocation-check disable
set system services extension-service request-response grpc ssl address 192.168.0.8
set system services extension-service request-response grpc ssl port 9339
set system services extension-service request-response grpc ssl local-certificate grpc-ecdsa-cert-01
set system services extension-service request-response grpc max-connections 30
set security certificates local grpc-ecdsa-cert-01 load-key-file /var/tmp/router-01.pem

The configuration passes commit check successfully. However, after commit, nginx fails.

The observed behavior is that nginx enters a restart loop and does not start successfully. No actual TCP listener is created for the configured gRPC SSL service, even though operational commands may still show the request-response server as Up.

The relevant nginx error is:

cannot load certificate "/var/db/nginx-certs/nginx_chain.cert": BIO_new_file() failed (SSL: error:80000002:system library::No such file or directory:calling fopen(/var/db/nginx-certs/nginx_chain.cert, r) error:10000080:BIO routines::no such file)

During troubleshooting, it was confirmed that /etc/nginx.conf only includes /var/etc/nginx/*. The generated file /var/etc/nginx/nginx.conf contains the following references:

ssl_certificate /var/db/nginx-certs/nginx_chain.cert;
ssl_certificate_key /var/db/nginx-certs/nginx_chain.cert;

However, on the affected router, /var/db/nginx-certs/nginx_chain.cert does not exist. Only /var/db/nginx-certs/nginx.cert is present.

This indicates a path or reference issue in the nginx configuration generated for extension-service request-response grpc ssl. The generated nginx configuration points to nginx_chain.cert, but that file is not created or made available on the affected system.

It was also confirmed that the issue is not related to the configured IP address or TCP port. Different values were tested and the behavior remained the same. The issue is specifically tied to enabling request-response grpc ssl and the way the nginx runtime configuration is generated.

• gRPC SSL request-response service appears Up, but is not functioning
• nginx fails to start and enters a restart loop
• Alarm is raised: Application nginx fail on node Re0
• No TCP listener is created for the configured gRPC SSL service

Based on these findings, this is a defect in certificate path handling or SSL artifact generation for system services extension-service request-response grpc ssl on Junos OS Evolved 24.4R2-S3.7-EVO. The service causes nginx to load a non-existent file, /var/db/nginx-certs/nginx_chain.cert, which results in nginx startup failure and the alarm:

Application nginx fail on node Re0

• This issue is tracked under PR1933395
• Fix version: 24.4R2-S5
• 24.4R2-S4 is also impacted and will not contain the fix because it was already built
• 25.2 and later correctly reference the certificate file as part of a gRPC subsystem overhaul

As a temporary workaround, create a symbolic link so the path expected by nginx resolves to the existing file:

cd /var/db/nginx-certs
ln -s nginx.cert nginx_chain.cert
systemctl restart nginx

This is only a temporary workaround and not a permanent fix. The underlying issue is that the system-generated nginx configuration references a certificate file that does not exist.