I'm trying to connect to a server using an SslStream. I've been given a PFX file from the owner of the server and I've installed it on my client but I'm not sure how to access the certificate from my code.
Specifically, imagine that I have the following code...
var serverName = "?";
var stream = new SslStream();
stream.AuthenticateAsClient(serverName);
What would the value of serverName be? I've tried
the IP address of the server
"MyServer"
"CN = MyServer"
None of these values seem to work. Is there something additional I need to do to access the cert store on my machine, or do I not understand what the serverName needs to be?
It must be the Common Name (CN - which is usually a fully qualified domain name) of the servers certificates subject for the host you are connecting to.
For example if the servers certificates subject looks like:
CN = www.verisign.com, OU = Production Security Services, O = VeriSign, Inc ...
you should use:
stream.AuthenticateAsClient("www.verisign.com");
If the host you are connecting to allows connections without client certificate verification then you should be able to connect to it (with a browser for example - if HTTPS) and see the server certificate, or you can try using OpenSSL client.
Related
I have a Debian GCP instance that I'm trying to run a Python gRPC server. My instance has a static IP and I'm trying to establish a secure channel between my remote instance (server) and a local client.
I have generated self-signed OpenSSL certificates on the server and I am using the same certificates on the client. To generate I've used:
openssl req -newkey rsa:2048 -nodes -keyout ML.key -x509 -days 365 -out ML.crt
My server is set up like so (the .key and .crt files are loaded with an open as 'rb'):
server_credentials = grpc.ssl_server_credentials(((private_key, certificate_chain,),))
self.server.add_secure_port('0.0.0.0:%d' % self.port, server_credentials)
self.server.start()
My client is set up as:
host = '78.673.121.16' #this is the instance's static IP
port = 9063
certificate_chain = __load_ssl_certificate() #this loads the certificate file
# create credentials
credentials = grpc.ssl_channel_credentials(root_certificates=certificate_chain)
# create channel using ssl credentials
channel = grpc.secure_channel('{}:{}'.format(host, port), credentials)
and then I proceed to make a request.
At the server I am met with the following error, in response to my request:
E1017 17:21:22.964227087 1881 ssl_transport_security.cc:1807] No match found for server name: 78.673.121.16.
I have tried to change the Common Name (CN) of the certificate to localhost, 0.0.0.0 and 78.673.121.16 but to no avail.
Is there any suggestion?
I just had a similar problem, and was able to get it resolved finally. In my case I was hosting the server in a kubernetes cluster with a static ip and port. The key components of the solution were (in the server certificate):
Use the static IP address as the Common Name
Add the static IP address as a DNSName within the SubjectAlternativeName extension of the certificate
Step 2 turned out to be critical. In python (using grpc version 1.34.0) this was accomplished by:
from cryptography import x509
host = '78.673.121.16'
builder = x509.CertificateBuilder()
...
builder = builder.add_extension(x509.SubjectAlternativeName([x509.DNSName(host)]), critical=False)
try passing these options in secure_channel function call
options = {
'grpc.ssl_target_name_override' : 'localhost',
'grpc.default_authority': 'localhost'
}
channel = grpc.secure_channel('{}:{}'.format(host, port), credentials, options)
I have failed to find how to solve this and have opted to set up a permanent DNS for my instance instead. I was using GCP which, as of the time of writing, doesn't staightforwardly provide a way to assign this to an instance.
I switched to Azure, assigned the DNS to my instance and used that DNS and CN on my self-signed SSL certificate.
After that I changed the client (the server remains as originally) as:
host = 'myinstance.westus.azure.com' #this is the instance's DNS
port = 9063
This resolved my issue.
Doesn't seem to find my certificate. When I visit site with https advise if certificate is out of date and points to when the domain was first set up doesn't seem to use or find the new certificates.
Have created new lets encrypt certs in plesk (CENT OS) and even as advised copied and moved said certs to a folder in /var/lib/couchdb/certs/
gave teh folder and certs CouchDB ownership and certs also set to 600 and edited .ini as follows and restarted CouchDB but just doesn't seem to work.
[daemons]
; enable SSL support by uncommenting the following line and supply the PEM's below.
; the default ssl port CouchDB listens on is 6984
httpsd = {chttpd, start_link, [https]}
[ssl]
cert_file = /var/lib/couchdb/certs/fullchain.pem
key_file = /var/lib/couchdb/certs/privkey.pem
Is there a way to check if SSL is correctly set up on a server, before pointing the domain at the server (the site has SSL on it's current server, and I want to make sure SSL is ready to go on the new server before I change the A record).
The site, on the new server, will not be in the root directory of the web server, so going to the server's IP address in my browser or using online SSL checker tools won't work (or is there a way to test just with IP address?).
The new server is Apache.
Thanks
Setup everything on the new server, then populate both its /etc/hosts and yours (or equivalent on your OS) with a mapping between its IP address and the name.
Hence at least the browser on your machine should, based on /etc/hosts query the new server, before you do the same change in the DNS for anyone else to see.
HTTPS and direct browsing by IP addresses does not mix well because:
certificates are based on hostnames, not IP addresses
with SNI, the client needs to pass an hostname at the TLS level for the server to properly select the certificate, in case of multihosting on a single IP address
If it's enough to test SSL/TLS, not HTTP level including things like redirects and linked resources (CSS, JS, images, etc)
openssl s_client -connect address:port -servername hostname_for_SNI </dev/null
# or <NUL: on Windows
# optionally add -quiet to suppress most non-error output
Currently in the process of moving an existing public facing site from Azure to our internal network. In order to retain the validity of the SSL (https) protocol I had to request another certificate for the the machine where the new site will reside.
I installed the cert on the system and it says it installed successfully but the site is showing a Certificate error in IE.
So I'm wondering if the fact that the CSR was created using the DNS name and the DNS hasn't yet been redirected to the new location; is the reason the Cert Error is being displayed?
The only way to access the new server is via IP address externally, not by the DNS name.
Does the site certificate get bound during creation to the DNS name of the server where it is supposed to reside or by the encrypted signature of the actual machine when the CSR (Certificate Signing Request) is generated?
Or is it both?
The only way to access the new server is via IP address externally, not by the DNS name.
I'm not fully sure what you are asking. But my interpretation of the question is that you have created a certificate for some DNS name (i.e. example.com) but then try to access the site by IP address since the DNS name is not available yet. And then you wonder why the browser complains (with an error you unfortunately not include in your question).
If my interpretation is correct then the reason for the browser error is that the hostname in the URL (i.e. the IP address you used) does not match the subject(s) of the certificate, i.e. the DNS name. This validation of name in URL against subject of certificate is an essential part of the certificate validation.
I have my website https://www.MyWebSite.com running on port 433. But I also have a admin login that only are available from the office local network http://MyServer:9999/Login.aspx. Both addresses points to the same site but different bindings.
Is it possible to get the one on port 9999 to use https? I tried creating a self signed certificate in IIS but my browser still complained, even though I exported the certificate and stored it in my CA Trusted root.
So just to sum everything:
My regular site: https://MyWebSite.com <-- working fine
My admin login, only accessible via local network: http://MyServer:9999/Login.aspx works fine.
When adding a selfsigned certificate issued to "MyServer" (not MyWebSite) and add the new binding on port 9999 I though to the website but Chrome is giving me a warning NET::ERR_CERT_COMMON_NAME_INVALID, even though the cert is Issued To MyServer and are trusted
Is it possible to get the one on port 9999 to use https?
yes it is possible to setup another port with selfsigned
certificate.
Normally Selfsigned certificate will have fully qualified machine name
e.g. machinename.subdomain.domain so you have to browse using https://machinename.subdomain.domain:9999/
Please double check what error you are running into ,In chrome
Your connection is not private
Attackers might be trying to steal your information from in08706523d (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
in IE,you may get
There is a problem with this website’s security certificate.
The security certificate presented by this website was issued for a different website's address.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
In that case,assuming you have given hostname as * in IIS binding, and also installed the selfsigned certificate installed your "Root Certification Authorities " You should be able to browse to
https://machinename.subdomain.domain:9999/ without any issues