New Winsock Gateway Control - CERT-VALIDATION - Revision history

Justin at 01:26, 29 March 2025

2025-03-29T01:26:03Z

← Older revision		Revision as of 01:26, 29 March 2025
Line 40:		Line 40:

	result$ = control(LUN, "SSL-ENABLE")		result$ = control(LUN, "SSL-ENABLE")
-	print "<<"; ~~strip(~~result$)	+	print "<<"; result$

	result$ = control(LUN, "CERT-VALIDATION VERIFY")		result$ = control(LUN, "CERT-VALIDATION VERIFY")
-	print "<<"; ~~strip(~~result$)	+	print "<<"; result$

	result$ = control(LUN, "CONNECT example.com 443", excp=tcperror)		result$ = control(LUN, "CONNECT example.com 443", excp=tcperror)

Justin at 00:49, 16 March 2025

2025-03-16T00:49:23Z

← Older revision		Revision as of 00:49, 16 March 2025
Line 1:		Line 1:
	== New Winsock Gateway (TCP Device) Control - CERT-VALIDATION ==		== New Winsock Gateway (TCP Device) Control - CERT-VALIDATION ==

-	A new CERT-VALIDATION control has been added to the ~~winsock~~ gateway (TCP Device) for managing SSL certificate verification ~~on the host side~~. ~~Using this new~~ control~~, you can tell~~ the ~~winsock~~ gateway ~~how to behave based on the certificate received~~ from the host.	+	As of Comet release 540, a new '''CERT-VALIDATION''' control has been added to the Winsock gateway (TCP Device) for managing SSL certificate verification. This control determines how the gateway handles certificates from the host.

	=== Usage ===		=== Usage ===

-	~~This control~~, like ~~the~~ SSL-ENABLE ~~control~~, must be ~~issued prior to~~ connecting to the remote server. ~~The syntax is as follows:~~	+	'''CERT-VALIDATION''', like '''SSL-ENABLE''', must be set before connecting to the remote server.

-	~~result$~~ = ~~control(LUN, "CERT-VALIDATION value")~~	+	==== Syntax ====

-	~~Where~~ value ~~can be one of three options:~~	+	result$ = control(LUN, "CERT-VALIDATION value")

-	~~VERIFY~~	+	Options:
-	~~VERIFY-AND-ASK (default)~~	+
-	~~DONOT-VERIFY~~	+

-	~~If the CERT-VALIDATION control is not specified, the default behavior is~~ VERIFY-AND-ASK.	+	*'''VERIFY'''
		+	*'''VERIFY-AND-ASK''' (default)
		+	*'''DONOT-VERIFY'''

-	~~=== Options ===~~	+	If not specified, or the control is not issued, the default behavior is '''VERIFY-AND-ASK'''.

-	==== ~~VERIFY~~ ====	+	==== Options ====

-	VERIFY	+	VERIFY

-	~~This option ensures~~ the certificate is valid before connecting. The connection will fail if verification fails~~. This is the recommended setting for security~~, ~~as the connection will not be allowed for~~ invalid or broken certificates.	+	Ensures the certificate is valid before connecting. The connection will fail if verification fails, preventing connections with invalid or broken certificates (recommended for security).

-	~~====~~ VERIFY-AND-ASK ~~====~~	+	VERIFY-AND-ASK (Default)

-	~~VERIFY-AND-ASK~~	+	Attempts verification and prompts the user if the certificate is invalid. This was the only behavior before Comet 540 and requires user confirmation before proceeding.

-	~~This is the default option, and was the only behavior prior to Comet release 540.~~	+	DONOT-VERIFY

-	~~Attempts~~ verification ~~and if there is an issue (~~invalid ~~or broken certificate) Comet will pop up a message box asking the user if they wan to trust the certificate~~. ~~This option is good to ensure the user is aware if the certificate is invalid,~~ but ~~requires user interaction~~ for ~~the XAP program to continue~~.	+	Skips verification, allowing connections even with invalid certificates. Useful for testing but not recommended for security reasons.

-	===~~= DONOT-VERIFY =~~===	+	=== Example ===

-	~~DONOT-VERIFY~~	+	For example, this code enables the SSL protocol, specifies that we will only accept valid certificates, then connects to the server:

-	~~Skips verification and allows connections even with invalid certificates.~~ ~~This option can be useful for testing with invalid or broken certificates~~, ~~but is not recommended for security reasons~~.	+	open(LUN) "TCP" excp=tcperror
		+
		+	result$ = control(LUN, "SSL-ENABLE")
		+	print "<<"; strip(result$)
		+
		+	result$ = control(LUN, "CERT-VALIDATION VERIFY")
		+	print "<<"; strip(result$)
		+
		+	result$ = control(LUN, "CONNECT example.com 443", excp=tcperror)

Justin: Created page with "== New Winsock Gateway (TCP Device) Control - CERT-VALIDATION == A new CERT-VALIDATION control has been added to the winsock gateway (TCP Device) for managing SSL certificate ve..."

2025-03-16T00:43:23Z

Created page with "== New Winsock Gateway (TCP Device) Control - CERT-VALIDATION == A new CERT-VALIDATION control has been added to the winsock gateway (TCP Device) for managing SSL certificate ve..."

New page

== New Winsock Gateway (TCP Device) Control - CERT-VALIDATION ==

A new CERT-VALIDATION control has been added to the winsock gateway (TCP Device) for managing SSL certificate verification on the host side. Using this new control, you can tell the winsock gateway how to behave based on the certificate received from the host.

=== Usage ===

This control, like the SSL-ENABLE control, must be issued prior to connecting to the remote server. The syntax is as follows:

result$ = control(LUN, "CERT-VALIDATION value")

Where value can be one of three options:

VERIFY
VERIFY-AND-ASK (default)
DONOT-VERIFY

If the CERT-VALIDATION control is not specified, the default behavior is VERIFY-AND-ASK.

=== Options ===

==== VERIFY ====

VERIFY

This option ensures the certificate is valid before connecting. The connection will fail if verification fails. This is the recommended setting for security, as the connection will not be allowed for invalid or broken certificates.

==== VERIFY-AND-ASK ====

VERIFY-AND-ASK

This is the default option, and was the only behavior prior to Comet release 540.

Attempts verification and if there is an issue (invalid or broken certificate) Comet will pop up a message box asking the user if they wan to trust the certificate. This option is good to ensure the user is aware if the certificate is invalid, but requires user interaction for the XAP program to continue.

==== DONOT-VERIFY ====

DONOT-VERIFY

Skips verification and allows connections even with invalid certificates. This option can be useful for testing with invalid or broken certificates, but is not recommended for security reasons.