I'm setting up a webserver is for development and testing purposes, strictly local, no access from the Internet, but needs to be conform the production environment as close as possible, including SSL.
So I have set up a local CA on the server, created a server request using SubjectAltNames for several nodes running on them, and signed it using the just created CA, and instructed apache to user this setup.
CN in both CA as server is tdc.nl - which is the 'domain' I'm using locally. It has sites manage.tdc.nl, www.tdc.nl, so in the server-request, I defined:
[ v3-req ]
...
subjectAltNames = #alt_names
...
[ alt_names ]
DNS.1 = tdc.nl
DNS.2 = manage.tdc.nl
DNS.3 = www.tdc.nl
DNS.4 = mail.tdc.nl
All names (except mail.tdc.nl) are registered in \Windows\System32\drivers\etc\hosts on the workstation that I use to access each of these servers, and in the server itself. I installed the CA certificate on my workstation as trusted base certificate as prompted in many descriptions.
Then I access https://manage.tdc.nl with different browsers.
Chrome signals NET::ERR_CERT_COMMON_NAME_INVALID, Edge signals DLG_FLAGS_SEC_CERT_CN_INVALID. Though both allow me to continue, I want to get on without error messages. However, it's weird that Firefox seems to be happy, even without installing the CA certificate, just accepts the link, and I can proceed without message.
I checked the server certificate and that notes the alternate names, but these are missing in the CA certificate. Should the subjectAlternateNames also be specified in the CA? The documentation I read doesn't show anything on that.
Doublechecked config for CA and docs I used: found I was missing
copy_extensions = copy
Redone signing, now subjectAltNames are in server certificate
After restarting Apache, it worked.
Related
Scenario:
We have a device similar to a WiFi router that has UI and API exposed
The device will run on any LAN out of our control, just like a WiFi router runs on any house.
The device doesn't belong to any domain and is accessed through its IP address (i.e. 192.168.1.100) with a browser.
The protocol shall be HTTPS
The software used is .net Core/Kestrel on Windows
Currently we have warnings in all browsers telling that the device has an invalid certificate.
Constraint: The device shall be accessible by any machine (desktop/tablet) and cannot install or configure anything in the client machines.
The question is:
What it the best way to remove the warning? We read that there cannot be regular certificates for private/local IPs.
Self-signed certificates seem to work for few days and then the error shows up again.
There is no way to issue SSL certificate for an IP address; you have to have an actual name which you create the certificate for. In order to get such a name, you need a DNS. Since you don’t have access to the internal DNS of that local network, you will have to use a public DNS server for this.
This assumes that devices within that network do actually have internet access. If they don’t, then you’re completely out of luck.
If there is internet access, then you can simply make a public (sub-)domain point to your local IP address. Basically, configure the DNS for a domain that you own so that there is an A entry on the domain or one of its subdomains, that points to your local IP address 192.168.1.100.
That way, you can communicate that public domain to others, and when they try to resolve the domain, they will hit the DNS which will give the local IP address. So devices within that network can then get to your device and access it. Since they are accessing it then through that domain, a certificate for that exact domain would be generally accepted.
In theory, this works pretty well. In practice this can be a bit complicated or expensive though. Server certificates expire, so you will have to include the certificate (securely!) inside your device and also provide some means to update it eventually when it would expire. Free certificates, like from letsencrypt, will expire within a few weeks, but money will be able to buy you certificates that expire less quickly.
But in the end, it will still be somewhat painful. But not because of the domain name, but rather because of the certificate – at least if you want a certificate that is automatically trusted. Otherwise, you would be back at the beginning.
So If I understand it corretly, without internet access and without
access to internal DNS, there is no way to allow clients (within local
network) to access a REST api listening on "some" device within the
local network over HTTPS. Right?
That is not correct. You can use a wildcard certificate, generated with e.g. openssl and communicate securely over TLS encryption. Just the signing is not trusted, so modern Browsers will show the big warning "Not secure". That is awfully wrong. It is way more secure compared to plain http, because it is not sure you're talking to the server you're expecting but you talk securely encrypted.
In plain http it will be enough to just listen the packets flying by. With https you need to pretend to be the server and issue a certificate and the right endpoints. So a much bigger effort and for most use cases in local networks a sufficient level of security.
Generate Certificate
#!/bin/bash
CONFIG="
HOME = /var/lib/cert
[ req ]
default_bits = 4096
default_md = sha256
distinguished_name = req_distinguished_name
prompt = no
x509_extensions = v3_req
[ req_distinguished_name ]
countryName= YourCountryCode
stateOrProvinceName= YourState
localityName= YourTown
organizationName= YourCompany
organizationalUnitName= YourUnit
commonName= *
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = email:whatever#localhost
"
openssl genrsa -out /var/usr/cert/name.key 4096
openssl req -x509 -new -nodes -key /var/usr/cert/name.key \
-config <(echo "$CONFIG") -days 365 \
-out /var/usr/cert/name.crt
Apply it to your service.
For browsers it'll show this big ugly message
For apps connecting to services you'll often need to set a flag, disabling signing checks like:
curl -k or --insecure
influx -ssl -unsafeSsl
(google helps for your application)
I have an Epson TM-T88V-i receipt printer which I print to using Epson's E-pos Javascript library. I have been using the following URL to print to the printer which is connected to my local network
http://192.168.1.105/cgi-bin/epos/service.cgi?devid=local_printer&timeout=60000
This has run fine while my application has been unsecured but I have now installed a certificate on my main domain to secure it from a trusted CA and have been facing the issue that when I print to the secure URL for the printer https://192.168.1.105/cgi-bin/epos/service.cgi?devid=local_printer&timeout=60000 it breaks the security of my main domain - flagging the site is not secure and crossing the HTTPS in red because it is loading content with certificate errors .
When I inspect the self-signed certificate generated by the printer it has the following issues:
Certificate - Subject Alternative Name missing The certificate for
this site does not contain a Subject Alternative Name extension
containing a domain name or IP address.
Certificate - missing This site is missing a valid, trusted
certificate (net::ERR_CERT_AUTHORITY_INVALID).
I have tried to add the certificate to my trusted certificate Authorities but this hasn't worked.
I have followed Epson's own guide to create a certificate using OpenSSL but I get the same error in my browser.
I have googled the above errors but just can't find a solution that works. Ignoring all Certificate errors is not an option as this is for a live production environment. I have enabled Allow invalid certificates for resources loaded from localhost and this too has not worked.
If I need to purchase certificate I will but don't know if A CA can issue one without a signing request
Any help will be greatly appreciated
This was the config that I got to work eventually from following this guide. Thanks to Mark Farrugia for pointing out to change the altNames from DNS.0 to IP.0 - This was what seemed to be the major sticking point for us
https://gist.github.com/jchandra74/36d5f8d0e11960dd8f80260801109ab0
#
# epson.cnf
#
[ req ]
prompt = no
distinguished_name = server_distinguished_name
req_extensions = v3_req
[ server_distinguished_name ]
commonName = 192.168.1.105
stateOrProvinceName = mystate
countryName = mycountry
emailAddress = myemail.email.com
organizationName = epson
organizationalUnitName = presales
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = #alt_names
[ alt_names ]
IP.0 = 192.168.1.105 -- this is the IP of the printer
It must be noted. I had to download the certificate and add it to Chrome's own trusted CA store on my other PC's. Once added It works as expected
Managed to sort the issue. Followed your tutorial but then make sure that when you come to the config of the actual certificate add IP.0 to the actual ip of the printer. Now my issue is that it does not connect to the printer using HTTPS through Javascript but a hack in the actual javascript should do it.
WHY: this is happen because of epson printer is not generated a valid certificated or untrusted by your PC, so it will block any connection to printer and have this warning like this image
HOW: go to your epson IP, then click process then PC will have printer certificate, then it can connect properly.
Go to this link and make some test:
https://xanhtool.github.io/epbex/
change this ip with your ip:
click send and get error:
open Advance and process:
send successful:
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
I followed this tutorial for creating Signed SSL certificates on Windows for development purposes, and it worked great for one of my domains(I'm using hosts file to simulate dns). Then I figured that I have a lot of subdomains, and that would be a pain in the ass to create a certificate for each of them. So I tried creating a certificate using wildcard in Common field as suggested in some of the answers at serverfault. Like this:
Common Name: *.myserver.net/CN=myserver.net
However, after importing this certificate into Trusted Root Certification Authority, I'm getting NET::ERR_CERT_COMMON_NAME_INVALID error in Chrome, for main domain and all of its subodmains, for example: https://sub1.myserver.net and https://myserver.net.
This server could not prove that it is myserver.net; its security certificate
is from *.myserver.net/CN=myserver.net.
This may be caused by a misconfiguration or an attacker intercepting your connection.
Is there something wrong in Common Name field that is causing this error?
Chrome 58 has dropped support for certificates without Subject Alternative Names.
Moving forward, this might be another reason for you encountering this error.
A workaround is to add the domain names you use as "subjectAltName" (X509v3 Subject Alternative Name). This can be done by changing your OpenSSL configuration (/etc/ssl/openssl.cnf on Linux) and modify the v3_req section to look like this:
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net
With this in place, not forget to use the -extensions v3_req switch when generating your new certificate. (see also How can I generate a self-signed certificate with SubjectAltName using OpenSSL?)
As Rahul stated, it is a common Chrome and an OSX bug. I was having similar issues in the past. In fact I finally got tired of making the 2 [yes I know it is not many] additional clicks when testing a local site for work.As for a possible workaround to this issue [using Windows], I would using one of the many self signing certificate utilities available.Recommended Steps:
Create a Self Signed Cert
Import Certificate into Windows Certificate Manager
Import Certificate in Chrome Certificate ManagerNOTE: Step 3 will resolve the issue experienced once Google addresses the bug...considering the time in has been stale there is no ETA in the foreseeable future.**As much as I prefer to use Chrome for development, I have found myself in Firefox Developer Edition lately. which does not have this issue.Hope this helps :)
Create openssl.conf file:
[req]
default_bits = 2048
default_keyfile = oats.key
encrypt_key = no
utf8 = yes
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = Cary
L = Cary
O = BigCompany
CN = *.myserver.net
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = #alt_names
[alt_names]
DNS.1 = myserver.net
DNS.2 = *.myserver.net
Run this comand:
openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt -config openssl.conf
Output files app.crt and app.key work for me.
Your wildcard *.example.com does not cover the root domain example.com but will cover any variant on a sub-domain such as www.example.com or test.example.com
The preferred method is to establish Subject Alternative Names like in Fabian's Answer but keep in mind that Chrome currently requires the Common Name to be listed additionally as one of the Subject Alternative Names (as it is correctly demonstrated in his answer). I recently discovered this problem because I had the Common Name example.com with SANs www.example.com and test.example.com, but got the NET::ERR_CERT_COMMON_NAME_INVALID warning from Chrome. I had to generate a new Certificate Signing Request with example.com as both the Common Name and one of the SANs. Then Chrome fully trusted the certificate. And don't forget to import the root certificate into Chrome as a trusted authority for identifying websites.
I think it may be a bug in chrome. There was a similar issue long back:
See this.
Try in a different browser. I think it should work fine.
If you're tired of this error. You can make Chrome not act out like this. I'm not saying it's the best way just saying it's a way.
As a workaround, a Windows registry key can be created to allow Google Chrome to use the commonName of a server certificate to match a hostname if the certificate is missing a subjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificates.
Data type: Boolean [Windows:REG_DWORD]
Windows registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
Windows/Mac/Linux/Android preference name: EnableCommonNameFallbackForLocalAnchors
Value: 0x00000001 (Windows), true(Linux), true (Android), (Mac)
To create a Windows registry key, simply follow these steps:
Open Notepad
Copy and paste the following content into notepad
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"EnableCommonNameFallbackForLocalAnchors"=dword:00000001
Go to File > Save as
Filename: any_filename.reg
Save as type: All Files
Select a preferred location for the file
Click on Save
Double click on the saved file to run
Click on Yes on the Registry Editor warning
Found this information on Symantec support page:
https://support.symantec.com/en_US/article.TECH240507.html
For everyone who is encountering this and wants to accept the risk to test it, there is a solution: go to Incognito mode in Chrome and you'll be able to open "Advanced" and click "Proceed to some.url".
This can be helpful if you need to check some website which you are maintaining yourself and just testing as a developer (and when you don't yet have proper development certificate configured).
Of course this is NOT FOR PEOPLE using a website in production where this error indicates that there is a problem with website security.
The answers provided did not work for me (Chrome or Firefox) while creating PWA for local development and testing. DO NOT USE FOR PRODUCTION! I was able to use the following:
Online certificate tools site with the following options:
Common Names: Add both the "localhost" and IP of your system e.g. 192.168.1.12
Subject Alternative Names: Add "DNS" = "localhost" and "IP" = <your ip here, e.g. 192.168.1.12>
"CRS" drop down options set to "Self Sign"
all other options were defaults
Download all links
Import .p7b cert into Windows by double clicking and select "install"/ OSX?/Linux?
Added certs to node app... using Google's PWA example
add const https = require('https');
const fs = require('fs'); to the top of the server.js file
comment out return app.listen(PORT, () => { ... }); at the bottom of server.js file
add below https.createServer({
key: fs.readFileSync('./cert.key','utf8'),
cert: fs.readFileSync('./cert.crt','utf8'),
requestCert: false,
rejectUnauthorized: false
}, app).listen(PORT)
I have no more errors in Chrome or Firefox
I have a unique situation where I need to implement client certificate authentication over HTTPS between IE browser and IIS 6. The browser and IIS are separated by a firewall that only allows the browser to connect to IIS on the SSL port.
We have an internal certificate server on the same network as IIS. I've generated an SSL server cert for IIS and that is installed. I configured IIS to only allow SSL, require client certificates.
The limitation here is the browser machine is on a disconnected network, so I can't go to the CA's http://caserver/CertSrv URL and request a client cert like you normally would.
I figured if there were a way that I could generate a CSR against the Root CA's public key, I can copy it to the CA server to generate the client cert. But, there appears to be no provision in IE or the Certificates MMC to do this. The Certificates MMC seems to require a direct connection to the CA.
Has anyone solved this before?
FYI, All servers referenced run Windows Server 2003.
Update: Thanks to Jonas Oberschweiber and Mark Sutton for pointing out the CertReq.exe command line tool. Using this, I've generated a CSR, and consequently a client certificate that installs successfully. However, IE is apparently not sending this client cert when accessing the IIS server in question; it still generates a 403.7 "Forbidden: SSL client certificate is required." I suspect that the reason is that the Subject field of the client cert does not match the user id of the account running IE, thus perhaps not sending a mismatching client cert. The Subject matches that of the user I used to submit the CSR and generate the client cert on the other end of the firewall.
Does the Subject field matter? Is there something else I need to do to enable IE to send this cert?
Use the certreq command on your client as follows
certreq -new -f filein c:\certrequest.req
Here is and example of the filein
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject="CN=dc1.extranet.frbrikam.com"
EncipherOnly = False
Exportable = False
KeyLength = 1024
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[RequestAttributes]
CertificateTemplate=TLSServer
Replace the CertificateTemplate with the name of your certificate template
Once you have your request file you need to take it to the certificate authority on a usb stick and use the web enrolment interface as usual to process the request file.
Take the output certificate back to the client open it and click install.
You sound like you have already tried a couple of things so my guess is that you are already aware of these, but I'm going to post them anyway, just in case: Certificate Command Line Tools. I am not sure, however, if they do what you want.
Go the http://caserver/CertSrv site that you mentioned using a 3rd computer that can see the CA server. Select the 3rd option, download a CA cert, cert chai, or CRL. On the next page select 'Download CA Certificate Chain', which will download the p7b file. Using a flash drive (or email, etc) transfer this to the other computer which will allow you to import it into the trusted root servers in IE.
http://technet.microsoft.com/en-us/library/cc787796.aspx
Suggestiong for the update, just in case - what is the trusted cert list of in the server?
Subject DN being the same as Windows username has never been a problem for me - although I don't use IIS much. However, somewhere in IIS there is sure to be a trusted certificate list. This error sounds to me like the server's trusted certs list does not include the CA or Root CA that issued the client certificate.
This is particularly true if you never get a certificate selection popup window in IE when you hit the IIS server - even though you have a certificate configured in your IE cert store. That means that the client hit the server, the server gave a list of trusted certs and the client didn't have a cert that fit the list. So the SSL session went to the Forbidden error state.
If the certificate selection window popped up, and you selected and sent the cert, there may be other configuration problems on the server side..