Skip to main content

Enabling HTTPS on the CxSAST Server

The following steps must be performed in order to enable HTTPS on the CxSAST Server.

1. Create a Certificate in IIS

Do one of the following:

2. Add a Binding to a Site in IIS

To add a binding to a site, refer to Add a Binding to a Site in IIS

3. Change web.config

Edit web.config as follows:

  1. Go to C:\Program Files\Checkmarx\CheckmarxWebPortal\Web

  2. Open web.config

  3. Edit the <add key="CxWSResolver.CxWSResolver"… element as follows:

    Change http://localhost/... to https:// <CertificateSubject>/...

Create a Self-Signed Server Certificate in IIS

Warning

By default, IIS 7 and above has a feature to create self-signed certificates. The certificates are signed with SHA-1, which is a hash that is no longer considered safe by modern browsers.

In order to create a self-signed certificate with SHA-256 (or any other crypto-spec) do the following:

  1. Create a new file called CxSelfSigned.ini.

  2. Enter the content below into CxSelfSigned.ini while replacing <your-server-name> with the server name (not localhost) that is going to be used by your users.

    [Version]
Signature="$Windows NT$

[Strings]; This is where you enter the server common name
szHOST_NAME = <your-server-name>

[NewRequest]
Subject = "CN=%szHOST_NAME%"
Requesttype = Cert
KeyLength = 2048
FriendlyName = "CxSelfSigned"
Exportable = false
HashAlgorithm = sha256
MachineKeySet = true
KeySpec = 1
KeyUsage = "CERT_KEY_ENCIPHERMENT_KEY_USAGE | CERT_DIGITAL_SIGNATURE_KEY_USAGE"

[EnhancedKeyUsageExtension]
; If you are using an enterprise CA the EnhancedKeyUsageExtension section can be omitted 

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

[Extensions]
; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.

2.5.29.17 = "{text}dns=%szHOST_NAME%"
; Multiple alternative names must be separated by an ampersand (&).


[RequestAttributes]
; If your client operating system is Windows Server 2003, Windows Server 2003 R2, or Windows XP
; and you are using a standalone CA, SANs can be included in the RequestAttributes 
; section by using the following text format.

;SAN="dns=%szHOST_NAME%"
; Multiple alternative names must be separated by an ampersand (&).

  3. Open a Command Prompt instance as Administrator.

  4. Navigate to the appropriate folder and enter:

    certreq -new CxSelfSigned.ini

    After a few seconds, the File Save dialog box appears.

  5. Press <Esc>. The new certificate is installed.

Creating a SAML Service Provider Application for OKTA

The connection between OKTA and Access Control is defined using a SAML service provider application in OKTA.

To create a SAML service provider application in OKTA:

  1. Login in to your OKTA administration account using your Username and Password credentials. The Launch Apps screen is displayed

    OKTA_111.png

  2. Click <Admin>. The OKTA Dashboard screen is displayed.

    OKTA_222.png

  3. Select the Applications tab and choose Applications. The Applications screen is displayed.

    OKTA_333.png

  4. Click Add Applications 2880570664.png. The Add Application screen is displayed.

    OKTA_444.png

  5. Click <Create New App>. The Create a New Application Integration screen is displayed.

    OKTA_555.png

  6. Under Platform, select Web and then check SAML 2.0.

  7. Click <Create> to continue. The Create SAML Integration screen is displayed.

    OKTA_666.png

  8. Enter the App Name as Checkmarx Access Control.

    Notice

    Optionally you can add a logo. To do so, click <Browse>, navigate to the desired logo and then upload it.

  9. Define the App visibility settings accordingly.

  10. Click <Next> to continue. The SAML Settings screen is displayed.

    OKTA_777.png

  11. Add the relevant information, provided by the downloaded Service Provider metadata file, to the following fields:

    Field

    Description

    Single sign on URL

    The location where the SAML assertion is sent with a HTTP POST. This is often referred to as the SAML Assertion Consumer Service (ACS) URL for your application. As defined in Service Provider metadata file under ‘Location’ (e.g., http{s}://{server}:{port}/CxRestAPI/auth/identity/samlAcs)

    Audience URI (SP Identity ID)

    The application-defined unique identifier that is the intended audience of the SAML assertion. This is most often the SP Entity ID of your application. As defined in Service Provider metadata file under ‘entityID’ (e.g., http{s}://{server}:{port}.

    Notice

    The Entity ID must be identical in both the Service Provider and the Identity Provider.

    Default RelayState

    This identifies a specific application resource in an IDP initiated single sign-On scenario. In most instances, this is blank.

    Notice

    If left blank the resource is, by default, directed to the defined Access Control URL. Optionally this can be defined as:

    • CxSAST Portal (Project State) – http{s}://{server}:{port}/cxwebclient/projectstate.aspx.

    • Management & Orchestration Portal – http{s}://{server}:{port}/cxarm/cxwebclient.

    When using the SAML IDP initiated login for cloud based services such as CxSCA, the tenant parameter must be added to the url in the relaystate.

    Examples:

    NA Account: https://sca.scacheckmarx.com?tenant={TENANT

    EU Account: https://eu.sca.checkmarx.net?tenant={TENANT}

  12. Click <Next> to continue.

  13. From the Feedback screen, select 'I'm an Okta customer adding an internal app' and then click <Finish>. The New Application screen is displayed.

    OKTA_888.png

  14. Click <View Setup Instructions>. The information provided on this page is used for Adding a new SAML Identity Provider in Access Control.

    Notice

    Alternatively, you can click the Identity Provider metadata link. The content of metadata.xml can be copied and saved to a text file.

In this section: