Preface

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customer access to and use of Oracle support services will be pursuant to the terms and conditions specified in their Oracle order for the applicable services.

Oracle is fully committed to diversity and inclusion. Oracle respects and values having a diverse workforce that increases thought leadership and innovation. As part of our initiative to build a more inclusive culture that positively impacts our employees, customers, and partners, we are working to remove insensitive terms from our products and documentation. We are also mindful of the necessity to maintain compatibility with our customers' existing technologies and the need to ensure continuity of service as Oracle's offerings and industry standards evolve. Because of these technical constraints, our effort to remove insensitive terms is ongoing and will take time and external cooperation.

Configuring Secrets at N32 Egress and Ingress Gateway

This section explains the steps to configure secrets for enabling HTTP over TLS in N32 Ingress and Egress Gateways. This procedure must be performed before deploying SEPP.

Note:

The passwords for TrustStore and KeyStore are stored in respective password files.
To create Kubernetes secret for HTTP over TLS, the following files are required:
  • ECDSA private key and CA signed certificate of SEPP (if initialAlgorithm is ES256)
  • or, RSA private key and CA signed certificate of SEPP (if initialAlgorithm is RSA256)
  • TrustStore password file
  • KeyStore password file
  • CA certificate

Note:

  • Creation process for private keys, certificates, and passwords is on discretion of user/operator.
  • f the certificates are not available, then create them following the instructions given in the 'Creating Private Keys and Certificates for Gateways' section.
You can manage Kubernetes secrets for enabling HTTPS in SEPP using one of the following methods:
  • Managing secrets through OCCM
  • Managing secrets manually

Managing Secrets Through OCCM

To create the secrets using OCCM, see "Managing Certificates" in Oracle Communications Cloud Native Core, Certificate Management User Guide.

The secrets created by OCCM are then patched to add keyStore password and trustStore password files by running the following commands:
  1. To patch the secrets created with the keyStore password file: 
    TLS_CRT=$(base64 < "key.txt" | tr -d '\n')
kubectl patch secret server-primary-ocsepp-secret-occm -n seppsvc -p "{\"data\":{\"key.txt\":\"${TLS_CRT}\"}}"
    Where,
    • key.txt is the password file that contains KeyStore password.
    • server-primary-ocsepp-secret-occm is the secret created by OCCM.
  2. To patch the secrets created with the trustStore password file:
    TLS_CRT=$(base64 < "trust.txt" | tr -d '\n')
kubectl patch secret server-primary-ocsepp-secret-occm -n seppsvc -p "{\"data\":{\"trust.txt\":\"${TLS_CRT}\"}}"
    Where,
    • trust.txt is the password file that contains TrustStore password.
    • server-primary-ocsepp-secret-occm is the secret created by OCCM.

Note:

To monitor the lifecycle management of the certificates through OCCM, do not patch the Kubernetes secrets manually to update the TLS certificate or keys. It must be done through the OCCM GUI.

Managing Secrets Manually

  1. Run the following command to create secret: 
    $ kubectl create secret generic <ocsepp-n32-secret> --fromfile=<ssl_ecdsa_private_key.pem> --from-file=<rsa_private_key_pkcs1.pem> --fromfile=<trust.txt> --from-file=<key.txt> --from-file=<caroot.cer> --fromfile=<ssl_rsa_certificate.crt> --from-file=<ssl_ecdsa_certificate.crt> -n <Namespace of SEPP deployment>
    Where,
    
<ocsepp-n32-secre> is the secret name for n32-egress-gateway and n32-ingress-agteway.
<ssl_ecdsa_private_key.pem> is the ECDSA private key.
<rsa_private_key_pkcs1.pem> is the RSA private key.
<trust.txt> is the SSL Truststore file.
<key.txt> is the SSL Keystore file.
<caroot.cer> is the CA root certificate authority
<ssl_rsa_certificate.crt> is the SSL RSA certificate.
<ssl_ecdsa_certificate.crt> is the SSL ECDSA certificate.
<Namespace> of SEPP deployment.

    Note:

    • Note down the command used during the creation of Kubernetes secret, this command will be used for updates in future.
    • It is recommended to use the same secret name as mentioned in the example. In case you change <ocsepp-n32-secret>, then update the k8SecretName parameter under n32-ingress-gateway and n32-egress-gateway section in the ocsepp_custom_values_<version>.yaml. For more information, see the n32-ingress-gateway and n32-egress-gateway section.
    Example: 
    
kubectl create secret generic ocsepp-n32-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=trust.txt --from-file=key.txt --from-file=caroot.cer --from-file=rsa_certificate.crt --from-file=ssl_ecdsa_private_key.pem --from-file=ocsepp.cer -n seppsvc
  2. Run the following command to verify the secret: 
    $ kubectl describe secret <ocsepp-n32-secret> -n <Namespace>
    Where, <ocsepp-n32-secret> is the secret name for n32-egress-gateway and n32-ingress-agteway and <Namespace> is the namespace of SEPP deployment.
    Example: 
    $ kubectl describe secret ocsepp-n32-secret -n seppsvc

Note:

If the certificates are not available, then create them following the instructions given in the 'Creating Private Keys and Certificates for Gateways' section.

Hosted SEPP Mode

This section explains the steps to configure secrets for enabling HTTP over TLS in N32 Ingress and Egress Gateways. This procedure must be performed before deploying SEPP.

Note:

The passwords for TrustStore and KeyStore are stored in respective password files.

Note:

When generating a CA certificate for SEPP TLS configuration, ensure that the ssl.conf file includes the following v3_ca extension:
[v3_ca]
basicConstraints = critical,CA:TRUE
keyUsage = critical,keyCertSign,cRLSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
This extension identifies the certificate as a Certificate Authority (CA) and authorizes it to sign other certificates. Without CA:TRUE and the required certificate-signing key usages, TLS validation can reject certificates issued by this CA.
To create Kubernetes secret for HTTP over TLS, the following files are required:
  • ECDSA private key and CA signed certificate of SEPP (if initialAlgorithm is ES256)
  • or, RSA private key and CA signed certificate of SEPP (if initialAlgorithm is RSA256)
  • TrustStore password file
  • KeyStore password file
  • CA certificate

Note:

  • Creation process for private keys, certificates, and passwords is on discretion of user/operator.
  • f the certificates are not available, then create them following the instructions given in the 'Creating Private Keys and Certificates for Gateways' section.
You can manage Kubernetes secrets for enabling HTTPS in SEPP using one of the following methods:
  • Managing secrets through OCCM
  • Managing secrets manually

Managing Secrets Through OCCM

To create the secrets using OCCM, see "Managing Certificates" in Oracle Communications Cloud Native Core, Certificate Management User Guide.

The secrets created by OCCM are then patched to add keyStore password and trustStore password files by running the following commands:
  1. To patch the secrets created with the keyStore password file: 
    TLS_CRT=$(base64 < "key.txt" | tr -d '\n')
kubectl patch secret server-primary-ocsepp-secret-occm -n seppsvc -p "{\"data\":{\"key.txt\":\"${TLS_CRT}\"}}"
    Where,
    • key.txt is the password file that contains KeyStore password.
    • server-primary-ocsepp-secret-occm is the secret created by OCCM.
  2. To patch the secrets created with the trustStore password file:
    TLS_CRT=$(base64 < "trust.txt" | tr -d '\n')
kubectl patch secret server-primary-ocsepp-secret-occm -n seppsvc -p "{\"data\":{\"trust.txt\":\"${TLS_CRT}\"}}"
    Where,
    • trust.txt is the password file that contains TrustStore password.
    • server-primary-ocsepp-secret-occm is the secret created by OCCM.

Note:

To monitor the lifecycle management of the certificates through OCCM, do not patch the Kubernetes secrets manually to update the TLS certificate or keys. It must be done through the OCCM GUI.

Managing Secrets Manually

  1. Run the following command to create secret: 
    
 kubectl create secret generic <ocsepp-n32-secret>
--from-file=ssl_ecdsa_private_key.pem	 
--from-file=rsa_private_key_pkcs1.pem 
--from-file=trust.txt 
--from-file=key.txt 
--from-file=caroot.cer 
--from-file=rsa_certificate.crt 
--from-file=ssl_ecdsa_certificate.crt 
--from-file=ocsepp.cer
--from-file=internal_fqdn.mcc111.mnc123.3gppnetwork_ssl_ecdsa_private_key.pem
--from-file=internal_fqdn.mcc111.mnc123.3gppnetwork_rsa_private_key_pkcs1.pem
--from-file=internal_fqdn.mcc111.mnc123.3gppnetwork_trust.txt
--from-file=internal_fqdn.mcc111.mnc123.3gppnetwork_key.txt
--from-file=bundle1.cer
--from-file=internal_fqdn.mcc111.mnc123.3gppnetwork_rsa_certificate.crt
--from-file=internal_fqdn.mcc111.mnc123.3gppnetwork_ssl_ecdsa_certificate.crt
--from-file=internal_fqdn.mcc111.mnc123.3gppnetwork_ocsepp.cer
--from-file=external_fqdn1.mcc123.mnc90.cer -n <namespace>
    Where,
    
<ocsepp-n32-secre> is the secret name for n32-egress-gateway and n32-ingress-agteway.
'ocsepp-n32-igw-secret' is the secret name for n32-ingress-gateway
'ocsepp-n32-egw-secret' is the secret name for n32-egress-gateway
<hosted_fqdn_ssl_ecdsa_private_key.pem> is the ECDSA private key for the hosted partner.
<hosted_fqdn_rsa_private_key_pkcs1.pem> is the RSA private key for the hosted partner.
<hosted_fqdn_trust.txt> is the SSL Truststore file for the hosted partner.
<hosted_fqdn_key.txt> is the SSL Keystore file for the hosted partner.
<hosted_fqdn_caroot.cer> is the CA root certificate authority for the hosted partner.
<hosted_fqdn_ssl_rsa_certificate.crt> is the SSL RSA certificate for the hosted partner.
<hosted_fqdn_ssl_ecdsa_certificate.crt> is the SSL ECDSA certificate for the hosted partner.

<external_fqdn_ssl_ecdsa_private_key.pem> is the ECDSA private key exposed towards the roaming partner.
<external_fqdn_rsa_private_key_pkcs1.pem> is the RSA private key exposed towards the roaming partner.
<external_fqdn_trust.txt> is the SSL Truststore file exposed towards the roaming partner.
<external_fqdn_key.txt> is the SSL Keystore file exposed towards the roaming partner.
<external_fqdn_caroot.cer> is the CA root certificate authority exposed towards the roaming partner.
<external_fqdn_ssl_rsa_certificate.crt> is the SSL RSA certificate exposed towards the roaming partner.
<external_fqdn_ssl_ecdsa_certificate.crt> is the SSL ECDSA certificate exposed towards the roaming partner.
<Namespace> of SEPP deployment.
    and rest are the default certificates that are created for the SEPP.

    Note:

    • Note down the command used during the creation of Kubernetes secret, this command will be used for updates in future.
    • It is recommended to use the same secret name as mentioned in the example. In case you change <ocsepp-n32-igw-secret> and <ocsepp-n32-egw-secret>, then update the k8SecretName parameter under n32-ingress-gateway and n32-egress-gateway section in the ocsepp_custom_values_<version>.yaml. For more information, see the n32-ingress-gateway and n32-egress-gateway section.
    • Hosted Partners with multiple FQDN can have different set of client certificates and CA bundle. In Hosted SEPP mode, user must add the client certificate of all hosted partners in the <ocsepp-n32-igw-secret> and <ocsepp-n32-egw-secret>.
    • SAN values present in the certificate should match the FQDNs configured in the multi FQDN configuration on N32 Ingress Gateway and N32 Egress Gateway.
    Example: 
    
kubectl create secret generic ocsepp-n32-secret --from-file=ssl_ecdsa_private_key.pem --from-file=rsa_private_key_pkcs1.pem --from-file=trust.txt --from-file=key.txt --from-file=caroot.cer --from-file=rsa_certificate.crt --from-file=ssl_ecdsa_private_key.pem --from-file=ocsepp.cer -n seppsvc
  2. Run the following command to verify the secret: 
    $ kubectl describe secret <ocsepp-n32-secret> -n <Namespace>
    Where, <ocsepp-n32-secret> is the secret name for n32-egress-gateway and n32-ingress-agteway and <Namespace> is the namespace of SEPP deployment.
    Example: 
    $ kubectl describe secret ocsepp-n32-secret -n seppsvc

Note:

If the certificates are not available, then create them following the instructions given in the 'Creating Private Keys and Certificates for Gateways' section.