IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

View Only

Back to Blog List

How To Setup IFA Using ISVA Lightweight Containers

By BEN STRAUBINGER posted Mon June 24, 2024 04:53 AM

With the 10.0.8 release of the IBM Security Verify Access product, the team has continued to improve its container support with the addition of a lightweight configuration container image.

In the legacy deployment scenario, the base ISVA image contained all of the configuration and runtime services. Over recent releases, these were separated out into lightweight container images for each service.

The addition of the lightweight configuration container provides the final piece of this new lightweight deployment model.

This post will outline the steps to configure the environment on a clean linux host with docker installed.

Host Environment

Update hosts file

Update the hosts file of the VM host with entries used to connect to the LMI config page and web reverse proxy:

127.0.0.2    config.docker-isva.ibm.com
127.0.0.3    www.docker-isva.ibm.com

Certificate files

Generate database and SSL certificate files

Generate postgres certificate:

$ mkdir -p ./certs/postgresql
$ openssl req -x509 -newkey rsa:4096 -keyout ./certs/postgresql/postgres.key -out ./certs/postgresql/postgres.crt -days 3650 -subj "/CN=postgresql/O=ibm/C=us" -nodes -addext "subjectAltName = DNS:postgresql"
Generating a 4096 bit RSA private key
.......................++++
........................................................................................................................++++
writing new private key to './certs/postgresql/postgres.key'
-----
$ cat ./certs/postgresql/postgres.crt ./certs/postgresql/postgres.key > ./certs/postgresql/postgres.pem

Generate SSL certificate: (see included file: openssl-docker-isva.cnf)

$ mkdir -p ./certs/ssl
$ openssl req -x509 -newkey rsa:4096 -keyout ./certs/ssl/docker-isva-key.pem -out ./certs/ssl/docker-isva-cert.pem -days 3650 -nodes -config ./openssl-docker-isva.cnf
Generating a 4096 bit RSA private key
...................................................................................................++++
......................................................................................................++++
writing new private key to './certs/ssl/dockermmfa-key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Some-State]:QLD
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:IBM Security
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:www.docker-isva.ibm.com   
Email Address []:
$ openssl pkcs12 -export -out ./certs/ssl/docker-isva-keystore.p12 -inkey ./certs/ssl/docker-isva-key.pem -in ./certs/ssl/docker-isva-cert.pem
Enter Export Password: Passw0rd
Verifying - Enter Export Password: Passw0rd

We should now have the following certificate and key files:

$ tree certs/
certs/
├── postgresql
│   ├── postgres.crt
│   ├── postgres.key
│   └── postgres.pem
└── ssl
    ├── docker-isva-cert.pem
    ├── docker-isva-key.pem
    └── docker-isva-keystore.p12

Import and trust browser certificate

Import the SSL certificate for your host OS and set it as trusted.

Starting containers

Postgres container

First, we need to start the database container using the latest verify-access-postgresql image from the IBM Container Registry (ICR).
We need to include the pgdata volume mount for persisting data, as well as mounting the postgresql certificate directory.
We supply the postgres username postgres and use the password Passw0rd.
We need to point to the postgres SSL keystore (using the mounted directory path), which will be at /var/local/postgres.pem.
We specify the database name isva and point to the server certificate we created earlier.
Lastly, we set the name and hostname of the container to postgresql, and specify to use the isva docker network.

$ docker run -t -d --restart always -v pgdata:/var/lib/postgresql/data -v ./certs/postgresql:/var/local -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=Passw0rd -e POSTGRES_DB=isva -e POSTGRES_SSL_KEYDB=/var/local/postgres.pem --hostname postgresql --name postgresql --network isva icr.io/isva/verify-access-postgresql:10.0.8.0

ISVA configuration container

Next, we need to start the ISVA configuration container using the verify-access-config image from ICR.
We need to include the isvaconfig volume mount for persisting data, which will be shared with the runtime and web reverse proxy containers.
We supply the admin user password Passw0rd.
We publish the local port to the bind address: 127.0.0.2:443 which will allow us to connect to the local management interface (LMI).
Lastly, we set the name and hostname of the container to isvaconfig, and specify to use the isva docker network.

$ docker run -t -d --restart always -v isvaconfig:/var/shared -e CONTAINER_TIMEZONE=Europe/London -e ADMIN_PWD=Passw0rd -p 127.0.0.2:443:9443 --hostname isvaconfig --name isvaconfig --network isva icr.io/isva/verify-access-config:10.0.8.0

ISVA web reverse proxy container

We can start the ISVA web reverse proxy container, though it won't be ready until we complete the required configuration steps.
This container uses the verify-access-wrp image from ICR.
We need to include the isvaconfig volume mount which will contain the configuration data.
We publish the local port to the bind address: 127.0.0.3:443 which will allow us to connect to the web reverse proxy.
We must specify the reverse proxy instance name, which must match the value we configure in later steps.
Lastly, we set the name and hostname of the container to isvawrp, and specify to use the isva docker network.

$ docker run -t -d --restart always -v isvaconfig:/var/shared -e CONTAINER_TIMEZONE=Europe/London -p 127.0.0.3:443:9443 -e INSTANCE=default --hostname isvawrp --name isvawrp --network isva icr.io/isva/verify-access-wrp:10.0.8.0

ISVA runtime container

We can start the ISVA runtime container, though it won't be ready until we complete the required configuration steps.
This container uses the verify-access-runtime image from ICR.
Again, we need to include the isvaconfig volume mount, which will contain the configuration data.
Lastly, we set the name and hostname of the container to isvaruntime, and specify to use the isva docker network.

$ docker run -t -d --restart always -v isvaconfig:/var/shared -e CONTAINER_TIMEZONE=Europe/London --hostname isvaruntime --name isvaruntime --network isva icr.io/isva/verify-access-runtime:10.0.8.0

Check running containers

We can see the status of the running containers with the docker ls command:

$ docker ls
CONTAINER ID   IMAGE                                           COMMAND                CREATED         STATUS                     PORTS                               NAMES
529a8f9c09eb   icr.io/isva/verify-access-runtime:10.0.8.0      "/sbin/bootstrap.sh"   2 minutes ago   Up 2 minutes (unhealthy)   9080/tcp, 9443/tcp                  isvaruntime
d2f65f58957c   icr.io/isva/verify-access-wrp:10.0.8.0          "/sbin/bootstrap.sh"   2 minutes ago   Up 2 minutes (unhealthy)   9080/tcp, 127.0.0.3:443->9443/tcp   isvawrp
f71996e3749e   icr.io/isva/verify-access:10.0.8.0              "/sbin/bootstrap.sh"   2 minutes ago   Up 2 minutes (healthy)     443/tcp, 127.0.0.2:443->9443/tcp    isvaconfig
0fd238cf042e   icr.io/isva/verify-access-postgresql:10.0.8.0   "/sbin/bootstrap.sh"   2 minutes ago   Up 2 minutes               5432/tcp                            postgresql

Note the "unhealthy" status of the runtime and web reverse proxy containers can be ignored until we have completed the required configuration steps.

Configuring the environment

First steps

Now the configuration container is started, we can connect to the LMI: https://config.docker-isva.ibm.com/
Login as the admin user:

Username: admin
Password: Passw0rd

To complete the First Steps wizard, we must first agree to the Software License Agreement.
On the second page we have the option of changing the admin password. We will skip this and keep our initial password.
Once the setup is completed, we can reload the LMI. The dashboard should now be shown.

Configure the runtime

Before configuring the runtime database, we need to import the postgresql certificate so the verify access containers can communicate with the database.
First, use the menu at the top of the screen to navigate to: System > SSL Certificates

Select the lmi_trust_store certificate database and import the signer certificate:

Certificate file: ./dockerkeys/postgresql/postgres.crt
Label: postgres

Next, select the rt_profile_keys certificate database and import the signer certificate:

Certificate file: ./dockerkeys/postgresql/postgres.crt
Label: postgres

After updating both certificate databases, deploy and publish the pending changes.

Now we have loaded the required certificate, we can configure the runtime database.
Navigate to: System > Database Configuration
Switch to the Runtime Database tab.
Configure the runtime database using the parameters we provided when starting the containers.
We can use the postgresql hostname, which docker networking should resolve to the correct address.
The username, password and database name were all provided when starting the postgresql container.

Type: PostgreSQL
Address: postgresql
Port: 5432
Secure: true
Username: postgres
Password: Passw0rd
DB Name: isva

Once configured, deploy and publish the pending changes.

Now, we can complete the Runtime configuration.
Navigate to: Web > Runtime Component
We will use the local LDAP server in this environment, so we just need to set the admin password.

User Registry: LDAP Local
Admin Password: Passw0rd

Once configured, deploy and publish the pending changes.

Finally, we need to activate the Base, AAC and FIM modules.
Navigate to: System > Activated Modules.
Import each of the license files, saving the configuration after uploading each file.
Once imported, deploy and publish the pending changes.

After activating the required modules, we must restart the config container:

$ docker stop isvaconfig && docker start isvaconfig

The environment is now configured with a local policy server and a local user registry.

Configure the web reverse proxy

Now we have the runtime configred, we can set up the web reverse proxy.

First we need to import the SSL certificate used when connecting to the reverse proxy.
Navigate to: System > SSL Certificates

Select the pdsrv certificate database and import the personal certificate:

Type: PKCS12
Certificate file: ./dockerkeys/ssl/docker-isva-keystore.p12
Password: Passw0rd

After updating the certificate database, deploy and publish the pending changes, then restart the runtime container:

$ docker stop isvaruntime && docker start isvaruntime

Now we can configure the reverse proxy instance.
Navigate to: Web > Reverse Proxy
Configure a new Reverse Proxy instance:

Instance name: default
Host name: isvawrp
Administrator password: Passw0rd

The remaining parameters can be left to their default values.
Once configured, deploy and publish the pending changes.

Next, we need to update the reverse proxy configuration to make use of our SSL certificate.
Select the new default instance and click the Edit button to show the reverse proxy configuration screen.
Switch to the SSL tab and update the SSL Server Certificate to use the www.docker-isva.ibm.com certificate.

Save the configuration update, deploy and publish the pending changes.

After publishing the new configuration, we can restart the wrp container:

$ docker stop isvawrp && docker start isvawrp

Create the test user

Before we can confirm the current configuration, we will need a test user to test basic username password authentication to the web reverse proxy.
Navigate to: Web > Policy Administration
Login as the sec_master user:

Username: sec_master
Password: Passw0rd

From the side menu, expand the User section and navigate to the Create User screen.
Create the test user with the following details:

User ID: testuser
Common name: testuser
Surname: user
Password: Passw0rd
Registry UID: cn=testuser,dc=iswga
Account valid: yes
Password valid: yes
GSO User: no
No Password Policy: no

Create the user, then navigate back to the LMI dashboard. You should see a pending change notification.
Deploy and publish the pending changes.

Restart the wrp and runtime containers:

$ docker stop isvawrp && docker stop isvaruntime && docker start isvaruntime && docker start isvawrp

Test the reverse proxy configuration

Now we have the reverse proxy configured, we can try to authenticate with our test user to confirm everything is working as expected.
Connect to the reverse proxy: https://www.docker-isva.ibm.com/
You should see the Application Gateway login screen.
Attempt to authenticate with the test username and password we just created:

Username: testuser
Password: Passw0rd

You should see a black screen with "IBM Security Verify Access" shown.

Configure the FIDO2 PAIR Scenario

Now we have our reverse proxy instance, we can configure it for use with our contex based access and authentication services.
Navigate to: Web > Reverse Proxy
Select the default instance and use the Manage dropdown to select: AAC and Federation Configuration > Authentication and Context Based Access Configuration
Complete the Authentication and Context Based Access Configuration wizard with the following settings: (note the easuser password differs from our existing admin passwords)

AAC Runtime:
- Hostname: isvaruntime
- Port: 9443
- Username: easuser
- Password: passw0rd
- Load certificate: yes
- Junction: /mga
FIDO2 PAIR:
- Configure Remember Me for FIDO2 PAIR: yes
- Remember Me Encryption Key Label: (www.docker-isva.ibm.com certificate label)
- Configure FIDO2 PAIR login template: yes
Reuse Options:
- Reuse certificates: yes
- Reuse ACLs: yes

After completing the configuration wizard, deploy and publish the pending changes, then restart the runtime and wrp container:

$ docker stop isvawrp && docker stop isvaruntime && docker start isvaruntime && docker start isvawrp

Next, we need to configure a FIDO2 Relying Party.
Navigate to: AAC > FIDO2 Configuration
Add a new relying party with the following settings:

Display name: www.docker-isva.ibm.com
Relying Party ID: www.docker-isva.ibm.com
Configuration mode: Simple Configuration

Save the new relying party configuration, deploy and publish the pending changes, then restart the runtime container:

$ docker stop isvaruntime && docker start isvaruntime

The IFA authentication scenario will make use of several authentication policies.
All of our authentication policies are disabled by default, so we will need to enable them before we continue.
Navigate to: AAC > Authentication
Use the dropdown menu to enable all authentication policies.

Once enabled, deploy and publish the pending changes, then restart the runtime container:

$ docker stop isvaruntime && docker start isvaruntime

Next, we need to configure the FIDO2 PAIR authentication scenario.
Navigate to: AAC > Authentication
Switch to the Scenarios tab, then open the Configure FIDO2 PAIR scenario wizard.

Complete the configuration with the following details: (note the LDAP Bind password differs from our existing admin passwords)

FIDO2 PAIR:
- FIDO2 Relying Party: www.docker-isva.ibm.com
Username Password:
- LDAP Hostname: 127.0.0.1
- LDAP Port: 6389
- LDAP Bind DN: cn=root,secAuthority=Default
- LDAP Bind Password: passw0rd
- SSL: no

Deploy and publish the pending changes, then restart the runtime container:

$ docker stop isvaruntime && docker start isvaruntime

Finally, we can configure the IFA authentication scenario.
For this scenario, we will offer the user the choice of username/password or Passkey authentication.
Navigate to: AAC > Authentication
Switch to the Scenarios tab, then open the Configure Identifier First Authentication scenario wizard.
Configure the IFA scenario with the following settings: (note the LDAP settings should already be populated)

IFA:
- FIDO2: yes
- MMFA: no
- Redirect: no
- FIDO2PAIR: yes
- Allow discovery: yes
FIDO2:
- Relying Party: www.dockermmfa.ibm.com
Username Password:
- LDAP Hostname: 127.0.0.1
- LDAP Port: 6389
- Bind DN: cn=root,secAuthority=Default
- Bind Pass: passw0rd
- SSL: false

Save the configuration, deploy and publish pending changes, then restart the runtime container:

$ docker stop isvaruntime && docker start isvaruntime

Test the IFA policy

Now we have completed the configuration, we can test the IFA policy with our test user to confirm everything is working as expected.
Connect to the reverse proxy and trigger the IFA scenario: https://www.docker-isva.ibm.com/mga/sps/authsvc/policy/ifa
You should see the Welcome screen with a Username input.

We start by entering the username for our test user:

Username: testuser

After clicking Continue, we are shown the Username Password screen, as we have not yet registered a Passkey.

Complete the login with the testuser details:

Username: testuser
Password: Passw0rd

After clicking the Sign In button and successfully authenticating, we are shown the Sign In Faster screen where we can now register our device.

Click the Yes button to start the device registration process.

Click the Let's Go button, which will prompt you to register your passkey device.

After completing the passkey registration, we are shown the Success page to indicate the registration was successful.

Now we can logout to unauthenticate before testing our Passkey login.
First, logout by navigating to the url: https://www.docker-isva.ibm.com/pkmslogout

Next, retrigger the IFA scenario: https://www.docker-isva.ibm.com/mga/sps/authsvc/policy/ifa
We are presented with the Welcome screen where we can again enter our test user's username.

This time, we are shown the Sign In Options screen where we are given the option of signing in using either our passkey device or password.

We can select the Security Key / Touch ID option and are prompted to authenticate with our passkey device.

After completing the sign in process, we are shown a screen confirming our login was successful.

This confirms our environment is configured correctly and the IFA scenario is working as expected.

Environment Cleanup

To clean up our environment, first stop and remove the running containers:

$ docker rm -fv isvawrp
$ docker rm -fv isvaruntime
$ docker rm -fv isvaconfig
$ docker rm -fv postgresql

Next, remove the Docker persistent volumes:

$ docker volume rm isvaconfig
$ docker volume rm pgdata

Finally, remove the Docker network:

$ docker network rm isva

3 comments

31 views

Permalink

https://community.ibm.com/community/user/blogs/ben-straubinger/2024/06/06/isva-lightweight-containers

Comments

Vũ Tuấn Anh

Thu October 31, 2024 10:50 PM

Thank you very much!

BEN STRAUBINGER

Sun October 13, 2024 07:51 PM

For reference, the `openssl-docker-isva.cnf` file used in the above example:

#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# This definition stops the following lines choking if HOME isn't
# defined.
HOME			= .
RANDFILE		= $ENV::HOME/.rnd

# Extra OBJECT IDENTIFIER info:
#oid_file		= $ENV::HOME/.oid
oid_section		= new_oids

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions		= 
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by 'ca' and 'req'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6

####################################################################
[ ca ]
default_ca	= CA_default		# The default ca section

####################################################################
[ CA_default ]

dir		= ./demoCA		# Where everything is kept
certs		= $dir/certs		# Where the issued certs are kept
crl_dir		= $dir/crl		# Where the issued crl are kept
database	= $dir/index.txt	# database index file.
#unique_subject	= no			# Set to 'no' to allow creation of
					# several ctificates with same subject.
new_certs_dir	= $dir/newcerts		# default place for new certs.

certificate	= $dir/cacert.pem 	# The CA certificate
serial		= $dir/serial 		# The current serial number
crlnumber	= $dir/crlnumber	# the current crl number
					# must be commented out to leave a V1 CRL
crl		= $dir/crl.pem 		# The current CRL
private_key	= $dir/private/cakey.pem# The private key
RANDFILE	= $dir/private/.rand	# private random number file

x509_extensions	= usr_cert		# The extentions to add to the cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt 	= ca_default		# Subject Name options
cert_opt 	= ca_default		# Certificate field options

# Extension copying option: use with caution.
# copy_extensions = copy

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions	= crl_ext

default_days	= 365			# how long to certify for
default_crl_days= 30			# how long before next CRL
default_md	= sha1			# which md to use.
preserve	= no			# keep passed DN ordering

# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy		= policy_match

# For the CA policy
[ policy_match ]
countryName		= match
stateOrProvinceName	= match
organizationName	= match
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional

# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName		= optional
stateOrProvinceName	= optional
localityName		= optional
organizationName	= optional
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional

####################################################################
[ req ]
default_bits		= 1024
default_keyfile 	= privkey.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes
x509_extensions	= v3_ca	# The extentions to add to the self signed cert

# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret

# This sets a mask for permitted string types. There are several options. 
# default: PrintableString, T61String, BMPString.
# pkix	 : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
# so use this option with caution!
string_mask = nombstr

# req_extensions = v3_req # The extensions to add to a certificate request

[ req_distinguished_name ]
countryName			= Country Name (2 letter code)
countryName_default		= AU
countryName_min			= 2
countryName_max			= 2

stateOrProvinceName		= State or Province Name (full name)
stateOrProvinceName_default	= Some-State

localityName			= Locality Name (eg, city)

0.organizationName		= Organization Name (eg, company)
0.organizationName_default	= Internet Widgits Pty Ltd

# we can do this but it is not needed normally :-)
#1.organizationName		= Second Organization Name (eg, company)
#1.organizationName_default	= World Wide Web Pty Ltd

organizationalUnitName		= Organizational Unit Name (eg, section)
#organizationalUnitName_default	=

commonName			= Common Name (e.g. server FQDN or YOUR name)
commonName_max			= 64

emailAddress			= Email Address
emailAddress_max		= 64

# SET-ex3			= SET extension number 3

[ req_attributes ]
challengePassword		= A challenge password
challengePassword_min		= 4
challengePassword_max		= 20

unstructuredName		= An optional company name

[ usr_cert ]

# These extensions are added when 'ca' signs a request.

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType			= server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
nsComment			= "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl		= http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]


# Extensions for a typical CA

subjectAltName=DNS:www.docker-isva.ibm.com

# PKIX recommendation.

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer:always

# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true

# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign

# Some might want this also
# nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy

# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF

[ crl_ext ]

# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.

# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always

[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType			= server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
nsComment			= "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl		= http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo

Vũ Tuấn Anh

Tue October 01, 2024 09:56 PM

Hello, could you please provide me with the openssl-docker-isva.cnf file? I am following an example but encountering issues with the certificate configuration

IBM Verify

IBM Verify

How To Setup IFA Using ISVA Lightweight Containers

By BEN STRAUBINGER posted Mon June 24, 2024 04:53 AM

Host Environment

Update hosts file

Certificate files

Generate database and SSL certificate files

Import and trust browser certificate

Starting containers

Postgres container

ISVA configuration container

ISVA web reverse proxy container

ISVA runtime container

Check running containers

Configuring the environment

First steps

Configure the runtime

Configure the web reverse proxy

Create the test user

Test the reverse proxy configuration

Configure the FIDO2 PAIR Scenario

Test the IFA policy

Environment Cleanup

Permalink

Comments

Additional
Resources

Office

Quick Links

IBM Verify

IBM Verify

How To Setup IFA Using ISVA Lightweight Containers

By BEN STRAUBINGER posted Mon June 24, 2024 04:53 AM

Host Environment

Update hosts file

Certificate files

Generate database and SSL certificate files

Import and trust browser certificate

Starting containers

Postgres container

ISVA configuration container

ISVA web reverse proxy container

ISVA runtime container

Check running containers

Configuring the environment

First steps

Configure the runtime

Configure the web reverse proxy

Create the test user

Test the reverse proxy configuration

Configure the FIDO2 PAIR Scenario

Test the IFA policy

Environment Cleanup

Permalink

Comments

Additional Resources

Office

Quick Links

Additional
Resources