Jump to content

Self signed SSL certificates


James Peterson

Recommended Posts

Yes, I have a number of apps/systems that still use self-signed certs (including the ISY).  I'm trying to switch to certs signed by my firewall (pfsense supports being a cert authority), but some of the older devices (like a vintage Synology NAS) don't have a sensible means to install certs (but I have no real excuse for not applying a cert to the ISY -- just lazy, and it's working, I guess...).

(I've looked at "real" certs -- too expensive.  And there's a "free" service, but the certs expire way too often, and it's such a PITA to install certs that way just doesn't make sense.)

Link to comment
Yes, I have a number of apps/systems that still use self-signed certs (including the ISY).  I'm trying to switch to certs signed by my firewall (pfsense supports being a cert authority), but some of the older devices (like a vintage Synology NAS) don't have a sensible means to install certs (but I have no real excuse for not applying a cert to the ISY -- just lazy, and it's working, I guess...).
(I've looked at "real" certs -- too expensive.  And there's a "free" service, but the certs expire way too often, and it's such a PITA to install certs that way just doesn't make sense.)


Question, I know where the certs are in pfsense but how are you making them certified via pfsense? Thanks in advance for the response.

Second I think pfsense has an add on where you can go out and get Let’s Encrypt certs and they can auto renew but haven’t done it/figured it out yet. Maybe peek at that?

MWarman also told me about wildcard SSL cert authority that was cheap(ish) but I need to find it in my notes/emails. Perhaps he will chime in. I’ll edit this post if I find it, but IIRC Hurricane Electric perhaps? he.net

Last, not sure with Sygnology, but QNAP has an actual cert app and you can buy one through them. However again not certain you can use it outside the NAS. Maybe worth looking into though?

Just trying to share and help.
Link to comment
MWarman also told me about wildcard SSL cert authority that was cheap(ish) but I need to find it in my notes/emails. Perhaps he will chime in. I’ll edit this post if I find it, but IIRC Hurricane Electric perhaps? he.net

  https://www.garrisonhost.com/ssl-certificates/alphassl.html

 

No relationship - just cheap SSL certs with a good trust root. $15/yr or $34 for 3 years as a single host cert. $45/yr or $105 for 3 years for a wildcard.

 

I have a wildcard on my pfSense - and now use haproxy to route requests inbound using SNI. It works well.

 

I do have a CA configured on pfSense as well - but I only use that for OpenVPN authentication (all certs used by OpenVPN are issued from this CA that’s trusted by thumbprint)

 

 

Link to comment
I use self-signed certificates. 


Which is perfectly adequate - as long as the certificate is installed as a trusted root on all devices that you use to access it - otherwise any third party can compromise your connection by using their own self-signed certificate (unless you manually verify the thumbprint each connection....)
Link to comment

Basically what I am trying to ascertain is whether I should support self signed certs in Agave.  Which I already do, but really whether I can or should remove it in the future.  If the ISY were easier to update the cert I don't think this would be an issue.    I just don't want to disable access to a users ISY because their cert expired. 

Link to comment

I really don't fully understand the difference between self-signed vs officially signed.  I know that my browser will give me a warning about self-signed because it can't confirm I am who I say I am, but when I'm dealing with myself, I don't need to prove who I am.  My primary goal in using ssl is to encrypt the transmission of my username/password.  Not to block someone from trying to guess my username/password.

Link to comment
I really don't fully understand the difference between self-signed vs officially signed.  I know that my browser will give me a warning about self-signed because it can't confirm I am who I say I am, but when I'm dealing with myself, I don't need to prove who I am.  My primary goal in using ssl is to encrypt the transmission of my username/password.  Not to block someone from trying to guess my username/password.

 

The problem with self signed - is anyone can self-sign. The certificate is not to prove the client to the site - it’s to prove the site is genuine to the connecting client. The security alert is telling you that it cannot tell if the site you are connecting to is fake or not.

 

So, an adversary can put a proxy in place that will dynamically generate a self-signed cert for your site - and present it to your browser. Without the trust anchor - you wouldn’t be able to tell the difference - and your username and password would be accessible to the proxy operator.

 

By proxy, this could be a Linux host on public WiFi arp spoofing the default gateway (an attack that forces all your traffic thru the attackers machine, where it can be intercepted).

 

Having your certificate issued by a trusted root - or adding your self signed cert to your device trusted root store avoids this false sense of security.

 

Simple rule. Either add your self signed cert to your trusted root store OR use publicly trusted certs. Don’t click thru invalid cert warnings - you cannot confirm that the self signed cert presented is YOUR self signed cert.

Link to comment
Basically what I am trying to ascertain is whether I should support self signed certs in Agave.  Which I already do, but really whether I can or should remove it in the future.  If the ISY were easier to update the cert I don't think this would be an issue.    I just don't want to disable access to a users ISY because their cert expired. 


I say support them. Present a warning to the user with the thumbprint of the cert when it’s not trusted by the device trust root - and ask the user to save the trust for that specific cert only.

As long as the cert is that same one, continue to allow the connection silently....

If it changes, tell the user that either the cert has changed on the device (allow a new trust to be established) - or let them know that their connection is probably being intercepted.

This is a technique called ‘certificate pinning’ - and it allows self-signed to be just as secure as trusted certs.
Link to comment


The problem with self signed - is anyone can self-sign. The certificate is not to prove the client to the site - it’s to prove the site is genuine to the connecting client. The security alert is telling you that it cannot tell if the site you are connecting to is fake or not.

So, an adversary can put a proxy in place that will dynamically generate a self-signed cert for your site - and present it to your browser. Without the trust anchor - you wouldn’t be able to tell the difference - and your username and password would be accessible to the proxy operator.

By proxy, this could be a Linux host on public WiFi arp spoofing the default gateway (an attack that forces all your traffic thru the attackers machine, where it can be intercepted).

Having your certificate issued by a trusted root - or adding your self signed cert to your device trusted root store avoids this false sense of security.

Simple rule. Either add your self signed cert to your trusted root store OR use public ally trusted certs. Don’t click thru invalid cert warnings - you cannot confirm that the self signed cert presented is YOUR self signed cert.


Always learning. Thanks for your through explication.
Link to comment
10 hours ago, MWareman said:

 

The problem with self signed - is anyone can self-sign. The certificate is not to prove the client to the site - it’s to prove the site is genuine to the connecting client. The security alert is telling you that it cannot tell if the site you are connecting to is fake or not.

 

So, an adversary can put a proxy in place that will dynamically generate a self-signed cert for your site - and present it to your browser. Without the trust anchor - you wouldn’t be able to tell the difference - and your username and password would be accessible to the proxy operator.

 

By proxy, this could be a Linux host on public WiFi arp spoofing the default gateway (an attack that forces all your traffic thru the attackers machine, where it can be intercepted).

 

Having your certificate issued by a trusted root - or adding your self signed cert to your device trusted root store avoids this false sense of security.

 

Simple rule. Either add your self signed cert to your trusted root store OR use publicly trusted certs. Don’t click thru invalid cert warnings - you cannot confirm that the self signed cert presented is YOUR self signed cert.

Wouldn't this require someone hack into the LAN I'm using?  To bypass the legit LAN gateway?  I could see that perhaps if I was using some public wifi, but I don't use public wifi.  I am typically using my office LAN to access my home ISY or I'm using my cell phone's LTE connection.  

 

And how would I add the trusted root to Agave or the ISY Java console?  Neither of those gives any warning about the self signed certificate. 

Link to comment

Did you import it into the ‘Trusted Root’ certificate store? (It’s not the default store).

You should get an extra warning about how importing into the root store is a highly trusted event and you you only do this for certificates you really trust - or something like that...

Link to comment
Did you import it into the ‘Trusted Root’ certificate store? (It’s not the default store).

You should get an extra warning about how importing into the root store is a highly trusted event and you you only do this for certificates you really trust - or something like that...
I dont believe Chrome uses the Windows certificate store. The cert has to be imported into Chrome's certificate store as well.

Sent from my SM-N9500 using Tapatalk

Link to comment
7 hours ago, MWareman said:

Did you import it into the ‘Trusted Root’ certificate store? (It’s not the default store).

You should get an extra warning about how importing into the root store is a highly trusted event and you you only do this for certificates you really trust - or something like that...

It's under (Win 10)

Certificates- current user

  - Trusted Root Certification Authorities

    -Certificates

 

EDIT:  But, still, I'm curious as to what if any impact this has when using other applications like ISY finder that don't seem to care that the certificate is self-signed.  Since I don't get any warning currently about the SSL being self-signed when using the ISY admin console, how would the presence of the certificate change anything.

Link to comment
I dont believe Chrome uses the Windows certificate store. The cert has to be imported into Chrome's certificate store as well.

Sent from my SM-N9500 using Tapatalk



It’s does. I manage over 3000 clients and all instances of Chrome use the Windows cert store for trusted root information.

Chrome does have its own additive lists (both added trusted and also blacklisted CA certs) as well...
Link to comment
It's under (Win 10)

Certificates- current user

  - Trusted Root Certification Authorities

    -Certificates

 

 

It has to be under ‘Certificates - Current System’ (something like that) - under the ‘Trusted Root Certification Authorities’ certificate location. You must be an admin to add the certificate to the store.

Link to comment
EDIT:  But, still, I'm curious as to what if any impact this has when using other applications like ISY finder that don't seem to care that the certificate is self-signed.  Since I don't get any warning currently about the SSL being self-signed when using the ISY admin console, how would the presence of the certificate change anything.

 

 

It only matters (currently) for the web console. If the admin interface goes HTML5, it will matter there as well...

 

Unfortunately, the admin console ignores invalid certificates and does not check the trust to a root cert. Unfortunately, it does this when connecting directly, to the portal URL or even the MobiLinc Connect URL - meaning the users credentials are vulnerable to man-in the middle SSL attacks. This is why I *never* run the admin console remotely like that - I either VPN to my home or I use a desktop remote control tool to run it locally.

 

 

Link to comment
1 hour ago, MWareman said:

 

It has to be under ‘Certificates - Current System’ (something like that) - under the ‘Trusted Root Certification Authorities’ certificate location. You must be an admin to add the certificate to the store.

Probably requires I "run as administrator"  I am running MMC from an admin logon, but still, Windows does this.

Link to comment

Ultimately, none of these so called security certificates mean a damn if no one follows established industry standards. One only needs to search for Symantec and what Google did to this vendor: https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html

Certificates are like warranties it's only as good as the company standing behind it ~ Period.

The entire world is based on the honor system and when it comes to money there is no honor among thieves. There are no less than five companies in 2005 ~ 2018 who have been caught issuing useless certificates. The industry has to come up with something else because this frame work simply doesn't work and is easily circumvented. My prediction is a new ultra hybrid https -> VPN connection that uses a local site to site terminal authentication.

Whether or not the general public will adopt such a communication measure is highly unlikely.

Seeing and testing this framework live thus far it works and no one on the red vs blue team has yet found a way to crack it!:lol:     

 

Link to comment
14 hours ago, MWareman said:

 

It has to be under ‘Certificates - Current System’ (something like that) - under the ‘Trusted Root Certification Authorities’ certificate location. You must be an admin to add the certificate to the store.

I tried 'certificates (local computer)'  Still it does not do anything.  You get 3 choices in MMC when creating a certificate snap-in: My account, Service Account, Computer Account.  I tried both my account and computer account.  I looked at Service Account which brings up a menu of a couple hundred services that could be running on your computer.  I have no idea what to do with that.

Link to comment
Ultimately, none of these so called security certificates mean a damn if no one follows established industry standards. One only needs to search for Symantec and what Google did to this vendor: https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html
Certificates are like warranties it's only as good as the company standing behind it ~ Period.
The entire world is based on the honor system and when it comes to money there is no honor among thieves. There are no less than five companies in 2005 ~ 2018 who have been caught issuing useless certificates. The industry has to come up with something else because this frame work simply doesn't work and is easily circumvented. My prediction is a new ultra hybrid https -> VPN connection that uses a local site to site terminal authentication.
Whether or not the general public will adopt such a communication measure is highly unlikely.
Seeing and testing this framework live thus far it works and no one on the red vs blue team has yet found a way to crack it!     
 
There are a couple competing methods to solve the CA trust problem.

HTTP Public Key Pinning (HPKP), where after the first time you connect to the web server, the browser stores a list of valid certificate hashes and warns the user if the certificate does not match one of those hashes.

The alternative is DNS-based Authentication of Named Entities (DANE), where you specify valid hashes as DNS records (which the CA doesn't control). The upside of DANE is that it would completely remove the need for CAs long-term. The downside is that it requires DNSSEC, otherwise the DNS responses could be forged.

Sent from my SM-N9500 using Tapatalk

Link to comment
I tried 'certificates (local computer)'  Still it does not do anything.  You get 3 choices in MMC when creating a certificate snap-in: My account, Service Account, Computer Account.  I tried both my account and computer account.  I looked at Service Account which brings up a menu of a couple hundred services that could be running on your computer.  I have no idea what to do with that.


Select ‘Computer Account’ in that first dialog.

Right-click ‘Certificates’ under the ‘Trusted Root Certification Authorities’ under ‘Certificates (Local Computer’ and select ‘Import’.

Select your self signed .cer file (it shouldn’t be the private key - or a .pfx).

Confirm your new trusted root is in the list.

Reboot.

1ee4f673a18554467d7bc20bb18f4f61.png
Link to comment
2 hours ago, MWareman said:

 


Select ‘Computer Account’ in that first dialog.

Right-click ‘Certificates’ under the ‘Trusted Root Certification Authorities’ under ‘Certificates (Local Computer’ and select ‘Import’.

Select your self signed .cer file (it shouldn’t be the private key - or a .pfx).

Confirm your new trusted root is in the list.

Reboot.

1ee4f673a18554467d7bc20bb18f4f61.png

 

This is precisely what I did.  The only difference is the exported file from ISY had no file type extension at all.  I told ISY to name the file "ISY" when doing the export which it did.  The name of the certificate itself is different.  The import said it was successful and the name of the certificate showing in the list of certificates is correct, so it obviously read and understood the file since that name was contained within the file.  From ISY dashboard, I opened the "server certificate" configuration and hit the "export" button at the bottom to create this file.  In the save as window, the only option for saving is "all files" and it put no extension on it at all.  Perhaps I am exporting the wrong thing?

Link to comment

Archived

This topic is now archived and is closed to further replies.


  • Recently Browsing

    • No registered users viewing this page.
  • Forum Statistics

    • Total Topics
      36.9k
    • Total Posts
      370.2k
×
×
  • Create New...