I have a WCF-BasicHTTP send port configuredas follows:
Security tab Security mode:Transport;
Transport client credential type: Certificate;
Client certificate: (thumbprint of our client cert);
Service certificate: (thumbprint of the service's public key cert).
General tab, Endpoint Identity: everything is left blank.
There is a send pipeline component that substitutes alternative endpoint addresses depending on the interaction type (all endpoints share the same base URL).
Recently, our trading partner has renewed their server certificate, and failed to notify us in advance. The send port continues working (good). However, the behaviour leads me to believe that even though BizTalk forced me to specify some service certificate thumbprint, the adapter then does not actually verify the service certificate thumbprint against what's set in the binding. I can't figure out if this is a bug or by design?
Related
We have a fleet of IoT devices, and want to proxy a port to an end user (remote diagnostics sessions). In order to avoid exposing the IP of our IoT devices, we want to proxy it to an end user. However, these IPs can be dynamic, and the proxy will of course need to be authenticated.
So the flow will be like this:
The user requests a remote diagnostic session;
Backend sends request to IoT device to check if the diagnostic service is running, and otherwise starts it;
IoT device starts the diagnostic service and replies with the status;
Backend creates a new secure proxy which proxies the IoT device to the end user with authentication;
Backend replies to the user with the ip and authorization tokens to connect to the proxy;
User connects to the diagnostic session through the proxy;
Now, I found only one solution thus far, which is Ceryx, however, it has no authentication. NGINX plus doesn't seem like an option, due to the significant license costs, but also due to the fact it doesn't seem to be able to handle this.
Are there any solutions besides adjusting Cyrex to support authentication?
With OpenResty you can set up your proxy using:
acces_by_lua request phase to authenticate your request
balancer_by_lua to handle a dynamic proxying
This can be easily achieved, but will require you to write some code.
How can the certificates inside a Corda network be signed by Certificate Authority? Is there a defined process for managing the certificates for each Node and participants in Corda network?
To join a Corda network a Node needs to obtain a certificate from the Identity Manager of the network they want to connect to. It is described in the documentation of Corda Enterprise:
To connect to a compatibility zone you need to register with its
certificate signing authority (or doorman) by submitting a certificate
signing request (CSR) to obtain a valid identity for the zone. This
process is only necessary when the node connects to the network for
the first time, or when the certificate expires. You could do this out
of band, for instance via email or a web form, but there’s also a
simple request/response utility built into the node.
Before using this utility, you must first have received the trust
store file containing the root certificate from the zone operator. For
high security zones, this might be delivered physically.
So, first the node operator needs to get in touch with the network operator offline and provide its X.509 information. The network operator will provide the node with:
truststore.jks, the network/zone operator’s root certificate in keystore with a locally configurable password as protection against
certain attacks
At this point the node can then use the node utilities to make a CSR (Certificate Signing Request) to the Identity Manager to obtain the node certificate and receive the following:
nodekeystore.jks, which stores the node’s identity key pairs and certificates
Note that this can be also provided directly by the network operatort, I guess it depends on their policy. It is also described in the documentation.
The node can also create its own sslkeystore.jks,
which stores the node’s TLS key pair and certificate
that can be used, for example, to connect an external RPC client to the node.
The node certificate expires and can be revoked by the Identity Manager, so in that case it needs to make other specific request to obtain a new certificate.
Further readings:
https://docs.corda.net/docs/corda-enterprise/4.8/network/permissioning.html
https://docs.corda.net/docs/cenm/1.5/pki-guide.html#certificate-hierarchy-guide
I received the following question. Any help would be greatly appreciated!
What I need to be able to do is configure SSL to validate the target endpoint’s SSL certificate against the base trusted roots (typically provided by the OS and/or Java). There is no documentation that tells me how to turn on SSL certificate validation or if I add a TrustStore if it will guarantee that the SSL cert is validated against that. The only tutorial I see that is related is for SSL Client Auth, which we are not using.
Validation of backend SSL server certificates is explained on this page. Note that the page documents how to achieve mutual authentication, where the gateway would both validate the target server's SSL certificate (which you want), and send a certificate to the target as identification (which you do not want).
To validate the target's certificate, you create a truststore and upload all certificates in the trust chain for your target server. The documentation mentions only uploading the target server's certificate (which works if your target server is using a self-signed cert), but you'll want to upload the entire trust chain of certificates if you are using a non-self-signed cert. Creating and uploading to the truststore is shown in step 6 on the page above.
Then, you'll want the target endpoint configuration to look like this:
<TargetEndpoint name="default>
<HTTPTargetConnection>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>false</ClientAuthEnabled>
<TrustStore>myTruststore</TrustStore>
<IgnoreValidationErrors>false</IgnoreValidationErrors>
</SSLInfo>
<URL>https://myservice.com</URL>
</HTTPTargetConnection>
</TargetEndpoint>
ClientAuthEnabled=false indicates that the gateway will not send a certificate to the target.
IgnoreValidationErrors=false will cause the connection to abort if the certificate returned by the target cannot be validated using the certificates in the truststore. IgnoreValidationErrors=false is the default, so you could leave it out and it would work as desired. However, if you are having problems communicating with your target server, it may be useful during testing to set the ignore flag to true to allow communication even if the certificate fails verification (just to isolate your problem). Just be sure to set it to false in production.
The xsd schema for the SSLInfo element can be found here.
I want to send a request to HTTPS adapter through BizTalk server 2009. My BizTalk adapter is dynamic and it's takes configuration details from database instead of directly mentioning it on server.
I have installed X509 certificate in my browser and imported it in MMC.
I am getting following error in my BizTalk
A message sent to adapter "HTTP" on send port "sndHL7" with URI "https://xxxxxxxxx/imm/test (https://xxxxxxxxxxxxx/imm/test)" is suspended.
Error details: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel
I searched for this error, but every where I got following response only :
Error: – Details: “The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Solution: The error message normally occurs if the client certificate is not configured correctly. You should check that you have configured your client certificate in certificate store under BizTalk service account that hosts the HTTP adapter.
I am not getting how to configure that certificate in proper certificate store. I have 3 files wih extension .cer, .cer and .pfx. The file with extension .pfx requires password to install it in any store.
Also, how to configure certificate under BizTalk service Account? Should I select "Service Account" while adding snap in in MMC and then select BizTalk service from the list of services.
I don't know about biztalk but if you are presenting a cert you need the associated private key. A cert is like a photo ID. It is hard to forge, but it still doesn't prove your identity unless you can present your face for someone to compare with the ID. Assuming the file extensions match the actual format of the files, the cer files are either DER, BER or PEM encoded certificates without the private key. So you need the pfx file. So if the proposed solution from the error message is correct, you need to find that password and install the certificate and private key from the PFX file into the store.
The two .cer files must be the root authority and server certificates and you must trust them.so you need to place them in your LOCAL MACHINE- Trusted Root Certification store. (use MMC)
Now the .pfx file will have the client authentication certificate that you will be passing into get authenticated. Import this certificate to LOCAL MACHINE,Personal (or MY certificate store if using command line) check private key as exportable.
Now allow BizTalk service account access to the private key of this certificate.
MMC use add snap in and add local machine.
select the client certificate in Personal right click- AllTasks- Manage private keys. Now add your BizTalk service account as a user and give access.
Or else use winhttpcertcfg tool in command line
I am about to setup SmarterMail v9.0 on our Windows 2008 server (IIS7) and would first like to know what some security considerations are when opening up port 25 and/or 587 - ie how to prevent relaying, etc.
Thank you.
You must not accept email from untrusted users/sources which is not bound for domains you control.
An open relay is a mail server which allows anyone on the Internet to email anyone else, without verifying that either the source or the destination is known - thus, a relay.
You can check that the source is known by looking for a trusted IP subnet, or by requiring authentication before mail can be sent (via LOGIN over TLS, GSSAPI [called "Integrated Windows Authentication" or whatever], X.509 client certs, or the like).
You can check that the destination is known by comparing it to the list of domains for which your mail server will be the "last stop" (or a relay to another domain you control).
Either a known source or a known destination should be sufficient, but you may also want to make sure that mail inbound for your domains is at least borderline valid (originates from a domain with an MX server, for instance).
Separately, you must be conscious of DoS issues (rate limit inbound mail), and the ability to use your server to send backscatter spam. Backscatter is when I connect to your mail server and say, "why yes, I am unsuspecting_target#not_my_domain.com, please queue up this message for not_an_address#yourdomain.com". Then your mail server delivers a "bounce" message to the unsuspecting target. To mitigate this, you can verify that the recipient is known before accepting mail, or limit the rate at which mail can be accepted from one host, or try to check that the host delivering a message is authorized to use that envelope sender.
These are all well-solved problems.