Two factor authentication

coffeecup25

If you have enabled strict user/CN matching and your adversary has access to your computer she can just look in the certificate and get the CN there so you are not hiding anything from anyone by jumping through those hoops.

Not if you rename the certificates and the config file and put the new names in config file. I do this and it's flawless. It takes 30 seconds.

As I mentioned above, openVPN very recently changed the client program so the last user id defaults into the prompt. Before this, this method was foolproof. They accidentally made it less secure with this convenience. If they change it back or if there's a way to make the default client user always blanks again - just like the password - it will be good again.

Derelict

The CN is in the certificate, dude. It has to be or the connection and strict CN/username matching will not work.

openssl x509 -text -in certificate.pem

Look for the CN= in the Subject:

coffeecup25

@Derelict:

The CN is in the certificate, dude. It has to be or the connection and strict CN/username matching will not work.

openssl x509 -text -in certificate.pem

Look for the CN= in the Subject:

Why do you keep arguing with me. Just spend 30 seconds renaming the ovpn file, the certs in the ovpn file and the actual certs on the pc. IT WORKS PERFECTLY. (except for the dumb OpenVPN change where the last user id automatically populates the field when you initiate a connection. It used to not do that, until very recently.)

*** ===> You continue to confuse the username with the file names on the PC. They are not the same thing even though pfSense names the file using the username as a part of the filename. (Please note that pfSense renames these files also but uses the userid as a part of the file name. I fix that security glitch with these changes. I'm doing exactly what pfSense does.)

The ovpn file calls the certificates. They could be named larry moe and curley joe on the pc as long as the same name is used in the ovpn file. The name on the server is not involved at this point.

the actual user id could be xyzbc123 for all it matters. It HAS to match the OpenVPN server.
The checkbox on the server that says CN must match username (or something like that) is checked.

example:

file tun01.ovpn (downloaded from pfSense and renamed)
dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA1
tls-client
client
resolv-retry infinite
remote xxxxxxxxxxx 443 tcp-client
lport 0
verify-x509-name "openvpn_routed" name
auth-user-pass
pkcs12 tun01.p12
tls-auth tun01.key 1
ns-cert-type server

Note the last few lines and the cert names! The certificate files in the folder were renamed to tun01.p12 and tun01.key

I've been doing this for over a year. on multiple devices with different usernames on each. All use the same pc file name - tun01 or tun02. On each, the actual user name is NOT tun01 or tun02 or anything even close. the username MUST MATCH the cert name. If you use the wrong username IT WILL NOT CONNECT - even if the username is an otherwise valid username on the server. IT WORKS FINE!

If OpenVPN goes back to blanking out the last userid used on the pc, it will again be foolproof.

Derelict

Renaming the file hides nothing from anyone. It is an unnecessary, useless step. That is my point. It is not a "security glitch."

The user name is STILL in the certificate bundle the file name references, in the clear.

$ openssl pkcs12 -in pfSense-a-udp-1195-testuser.p12
Enter Import Password:
MAC verified OK
Bag Attributes
localKeyID: CD 83 F7 D9 A2 44 34 6E 0F CD 5D DD B4 C2 BD 38 C6 7E AB A8
subject=/C=US/ST=Nevada/L=Las Vegas/O=Test OpenVPN/emailAddress=derelict@example.com/CN=testuser
issuer=/C=US/ST=Nevada/L=Las Vegas/O=Test OpenVPN/emailAddress=derelict@example.com/CN=test-openvpn-ca
–---BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIBCDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMx
DzANBgNVBAgTBk5ldmFkYTESMBAGA1UEBxMJTGFzIFZlZ2FzMRUwEwYDVQQKEwxU
ZXN0IE9wZW5WUE4xIzAhBgkqhkiG9w0BCQEWFGRlcmVsaWN0QGV4YW1wbGUuY29t

coffeecup25

@Derelict:

Renaming the file hides nothing from anyone. It is an unnecessary, useless step. That is my point. It is not a "security glitch."

The user name is STILL in the certificate bundle the file name references, in the clear.

$ openssl pkcs12 -in pfSense-a-udp-1195-testuser.p12
Enter Import Password:
MAC verified OK
Bag Attributes
localKeyID: CD 83 F7 D9 A2 44 34 6E 0F CD 5D DD B4 C2 BD 38 C6 7E AB A8
subject=/C=US/ST=Nevada/L=Las Vegas/O=Test OpenVPN/emailAddress=derelict@example.com/CN=testuser
issuer=/C=US/ST=Nevada/L=Las Vegas/O=Test OpenVPN/emailAddress=derelict@example.com/CN=test-openvpn-ca
–---BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIBCDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMx
DzANBgNVBAgTBk5ldmFkYTESMBAGA1UEBxMJTGFzIFZlZ2FzMRUwEwYDVQQKEwxU
ZXN0IE9wZW5WUE4xIzAhBgkqhkiG9w0BCQEWFGRlcmVsaWN0QGV4YW1wbGUuY29t

I just looked at my three files downloaded for pc config. These's no reference to the username. Perhaps it's there for different client downloads for different platforms. In other words, it works for me on my windows laptops but might not if I were not using a pc.
I just downgraded to openvn 2.3.14. The username is not preloaded as a default in this version. I'm secure again.

Derelict

Horse. Water.

coffeecup25

@Derelict:

Horse. Water.

Download the standard archive and unzip it. You will get a folder with three files - none have a CN like your download files. I think the android or an inline download will, however.

If you don't believe me, believe your own eyes. Actually download one and look. Anyone with pfsense can do the same. They will see what I am describing.

One of the standard archive files looks encrypted - the p12 I think . It's probably in there somewhere ENCRYPTED.

edit: I had put excerpts from actual files here but decided against it and edited them out. Even a partial file is a security issue. I can create a fake user and download a profile if you're to unmotivated to see for yourself.

edit 2: No changed my mind. Your debating gravity. I'm done Trust me, it really exists. I described a very safe method for two plus factor security that anyone with a pc can use. It apparently won't work unless you use the standard zipped archive files. And OpenVPN 2.3.14 since newer versions retain the last used username field contents. I use it on my pc windows laptops and what I said can be validated in a few seconds by anyone with even a little self motivation.

JeGr

@coffeecup25 I simply don't get what you are talking about. You take those files from the standard archive and rename them. Fine.
So now they aren't named like <firewallname>-<proto>-<port>-<user>.any but are called fred.p12, fred.key and fred.ovpn. Fine again.
Your real VPN user name is - just for example purposes -> fr3d981.

So you say nothing in those files point to that name? That isn't the case with strict user CN matching active. With that option, your VPN user fr3d981 must have a matching cert with correct common name belonging to said name. So as @Derelict tries telling you, the .p12 file has this name in its CN Tag encoded. Thats nothing you can simply rename as the certificate itself is created with it.

We use that for remote access type of OpenVPN Servers all the time and regardless of using it in windows only or on Android, Linux, Mac or whatever, you can check on the correct username via certificate on all these systems because the CN simply HAS to match, otherwise it would not fulfill that option. And if you don't use strict user CN matching, you could use any cert valid from the same CA as a login factor, that's not what many of us wants. Just out of curiosity I checked a few of those "standard archive" packages and any .p12 file has its CN= value correctly set to the username it needs for logging in. Anything else would be very strange indeed.

And NO, this is not "encrypted" anywhere in the certificate but plain text readable as those certificated created via pfSense and the webGUI don't have a password set on them. You just hit enter.

Example:


Enter Import Password: (just hit enter)

MAC verified OK
Bag Attributes
    localKeyID: 4D 73 A3 1B A8 30 CC E1 E4 70 8E 21 90 2A 4F C6 37 91 7C 89
subject=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=jegr/OU=VPN
issuer=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=Company - VPN/OU=VPN

I x'ed the other values as they aren't important but the CN from the subject line. Regardless how you name the file, the CN is always there. Sorry, but I don't see how your renaming would add any security if you can check the username with a simple call to "openssl pkcs12 -in <certname>" - seems more like obscurity without security gain. No offense.

Greets</certname></user></port></proto></firewallname>

coffeecup25

@JeGr:

@coffeecup25 I simply don't get what you are talking about. You take those files from the standard archive and rename them. Fine.
So now they aren't named like <firewallname>-<proto>-<port>-<user>.any but are called fred.p12, fred.key and fred.ovpn. Fine again.
Your real VPN user name is - just for example purposes -> fr3d981.

So you say nothing in those files point to that name? That isn't the case with strict user CN matching active. With that option, your VPN user fr3d981 must have a matching cert with correct common name belonging to said name. So as @Derelict tries telling you, the .p12 file has this name in its CN Tag encoded. Thats nothing you can simply rename as the certificate itself is created with it.

We use that for remote access type of OpenVPN Servers all the time and regardless of using it in windows only or on Android, Linux, Mac or whatever, you can check on the correct username via certificate on all these systems because the CN simply HAS to match, otherwise it would not fulfill that option. And if you don't use strict user CN matching, you could use any cert valid from the same CA as a login factor, that's not what many of us wants. Just out of curiosity I checked a few of those "standard archive" packages and any .p12 file has its CN= value correctly set to the username it needs for logging in. Anything else would be very strange indeed.

And NO, this is not "encrypted" anywhere in the certificate but plain text readable as those certificated created via pfSense and the webGUI don't have a password set on them. You just hit enter.

Example:
Enter Import Password: (just hit enter)

MAC verified OK
Bag Attributes
    localKeyID: 4D 73 A3 1B A8 30 CC E1 E4 70 8E 21 90 2A 4F C6 37 91 7C 89
subject=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=jegr/OU=VPN
issuer=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=Company - VPN/OU=VPN
I x'ed the other values as they aren't important but the CN from the subject line. Regardless how you name the file, the CN is always there. Sorry, but I don't see how your renaming would add any security if you can check the username with a simple call to "openssl pkcs12 -in <certname>" - seems more like obscurity without security gain. No offense.

Greets</certname></user></port></proto></firewallname>

If it's encoded then it's encrypted because nothing is readable in that file. NOTHING. Yet OpenVPN works fine and it won't connect unless the username matches the CN on the certificate. I used to work in IT and it frustrated me to no end when people argued about gravity even when proof of gravity was right in front of their nose. Generally they were thinking of things that had nothing to do with the example at hand yet resisted change and used arguing with gravity to fight change. IT people are by far the most resistant to new idea people I have ever met in my long life. If you can't fight gravity, then look for 'inconsistencies' or destroy reputations if all else fails. Ah … the good old days.

The excerpt in your post did not come from the p12 file I referenced. The reason I know is that some of it is humanly readable. Nothing in my p12 file is. So you must be looking in the wrong place ... the place that does work as you described ... not the place that works as I describe.

OpenVPN apparently supports several client config file formats. Your favorite will not support my objective. Mine does.

Or - just spitballing here - perhaps the CN field you see is not the CN the client program references to validate matching. Maybe the server does that using another method that matches the username to the certificate in use and, on the server, to the certificate the username should be using? Therefore, it's use is for something other than matching and an alternate OpenVPN client format does not necessarily require it. Just a guess.

Actually try it and you will see what I mean. Really. Gravity exists. I use it frequently.

You try to help someone out and get ganged up on by people who shriek ... "I don't do it that way and I never heard of it so it can't work and you are wrong. I will argue with you about it and ignore everything you say until you agree I am smarter than you." Why do I bother?

Derelict

It's encoded with pkcs12 but it is NOT encrypted, bro. It's there for anyone to see.

SEE ALSO: pkcs12(1)

This is not "encrypted" either:

coffeecup25

@Derelict:

It's encoded with pkcs12 but it is NOT encrypted, bro. It's there for anyone to see.

SEE ALSO: pkcs12(1)

This is not "encrypted" either:
-----BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIBCDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMx
DzANBgNVBAgTBk5ldmFkYTESMBAGA1UEBxMJTGFzIFZlZ2FzMRUwEwYDVQQKEwxU
ZXN0IE9wZW5WUE4xIzAhBgkqhkiG9w0BCQEWFGRlcmVsaWN0QGV4YW1wbGUuY29t

I just used notepad++ find - not there. Deal with it.

kpa

@coffeecup25:

@Derelict:
It's encoded with pkcs12 but it is NOT encrypted, bro. It's there for anyone to see.

SEE ALSO: pkcs12(1)

This is not "encrypted" either:
-----BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIBCDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMx
DzANBgNVBAgTBk5ldmFkYTESMBAGA1UEBxMJTGFzIFZlZ2FzMRUwEwYDVQQKEwxU
ZXN0IE9wZW5WUE4xIzAhBgkqhkiG9w0BCQEWFGRlcmVsaWN0QGV4YW1wbGUuY29t
I just used notepad++ find - not there. Deal with it.

Of course you won't find it like that. Derelict is just trying to give a subtle hint that there is something that you haven't grasped yet. The file is ASCII-armored using a base64 encoding that protects the file from being mangled when it passes trough a transfer channel that is not 8-bit clean. If you open the ASCII-armored file with proper tools (the openssl command line tool for example) the encoding is removed and all of the details of the certificate are open for everyone to see in plain text including the CN field.

johnpoz

"If it's encoded then it's encrypted because nothing is readable in that file"

Wow.. Talk about not understanding the basics…

Its encoded, not encrypted.. You really need to look up the difference..

Lets try and use an example you might understand. You speak english, if I tell you something in Latin or French or German.. Your not going to understand what it says. But someone that speaks latin or french or german would. You can translate it to english without having to "decrypt" anything.. You just have to understand the language its encoded with.

If its encypted.. Say with a keyed ceaser as simple example. It might be english but you can not understand it without "decryption" and know what the key or how to decrypt it even if you speak english.

You may not read or speak "ASCII-armored using a base64 encoding" but the programs do and simple as translating them into english for you. Its like taking the french sentence and pasting it into google translate.

But if I encrypt the english, french, latin you can paste it into google translate and all you will get back is gibberish..

Something that is encrypted can not be translated by anyone that knows how to use google.. Encryption requires you have/know what the key to the cipher to be able to translate it..

Here is online version of decoder for a pem file
https://www.sslshopper.com/certificate-decoder.html

Take your cert and paste in its info from certs you think are so "encrypted"

coffeecup25

@johnpoz:

"If it's encoded then it's encrypted because nothing is readable in that file"

Wow.. Talk about not understanding the basics…

Its encoded, not encrypted.. You really need to look up the difference..

Lets try and use an example you might understand. You speak english, if I tell you something in Latin or French or German.. Your not going to understand what it says. But someone that speaks latin or french or german would. You can translate it to english without having to "decrypt" anything.. You just have to understand the language its encoded with.

If its encypted.. Say with a keyed ceaser as simple example. It might be english but you can not understand it without "decryption" and know what the key or how to decrypt it even if you speak english.

You may not read or speak "ASCII-armored using a base64 encoding" but the programs do and simple as translating them into english for you. Its like taking the french sentence and pasting it into google translate.

But if I encrypt the english, french, latin you can paste it into google translate and all you will get back is gibberish..

Something that is encrypted can not be translated by anyone that knows how to use google.. Encryption requires you have/know what the key to the cipher to be able to translate it..

Here is online version of decoder for a pem file
https://www.sslshopper.com/certificate-decoder.html

Take your cert and paste in its info from certs you think are so "encrypted"

Looks like we're playing a game of telephone now and the original objective has been lost to technobabble.

The objective was to download the standard three file archive folder, zipped. Then rename the files and modify the ovpn file to reflect the new file names. This obfuscates the actual username which adds more security to the client assuming the server is matching client names to common names associated with the certificate.

From there we went to … "no no you can't do it cause I never heard of that before". Well, I do it and the cn is not in any of the files I unzipped and put into the config folder. Look for yourself. If it's encoded but not encrypted who cares. It's still unreadable unless you apply some weird forensics to it. Nobody will do that except possibly the FBI or a bored ET like hacker who lives in a basement and hasn't a life otherwise. And they need possession of the laptop to do it and want to do it, as opposed to just selling it for a few bucks on ebay after they stole it. Even so, no CN to see if they steal my windows laptops. Sorry about yours, you should do it my way. Even if ET does steal my laptop, it takes 2 seconds to delete the certificates. ET is locked out.

Your reply, in this context, makes no sense at all.

I've looked. It's not there. Lots of user IDs and even after a full server rebuild after I decided to start from scratch on everything again. Still zip with the CN in any file downloaded using the standard archive. As I said, I don't know or care about any of the other file formats that can be downloaded using the client export package because I'm only interest in what works. If it's encoded and not encrypted, who cares? It's still unreadable.

Even assuming ET gets my laptop and happens to have a translator with him that can decode the file that hides my username ... assuming it takes that much work and there's that kind of coincidence - I'm still pretty well protected using my system as the alternative is full disclosure if another type of file is downloaded using the client export package. Then anyone can see it in that case. Most people won't know anything about ET's skill set. I know, ET is lurking in your bedroom closet just waiting to grab your openvpn device.

Why so much hostility for a little good advice. Dilbert describes brittle IT people brilliantly.

johnpoz

"It's still unreadable. "

It is still readable.. And the common name on the cert is still .2 seconds to pull out of the encoded cert.. If you want to use a different user name for the account the user has to know that is different than the common name on the cert that is one thing. But don't think your creating any extra security by just renaming the cert from johnpoz to john. The CN of johnpoz is still in the cert and easy to view.

If your server is set up (box checked) for common name to match certificate

For example, pfSense names the file and the certs with the user id. Rename them and edit config with the new names. It's a little tedious but nobody knows your name if you do it.

Your talking about the attached check box right - see attached.

The point trying to get across to you is even if you rename the cert or config file so it doesn't have the user name on it - its still in the CERT file, while sure grandma can not read it.. But anyone else could with the simple url I posted..

So here is test cert I created.

I can call/rename this cert anything I want.. So sure pfsense calls it say

pfsense-TCP-443-billy.p12

that p12 has the cert in it, can be de-encoded and show you the CN or username that has to match. Your just causing yourself extra work if you think this is adding security from anyone other than say your grandma.

Not sure where you think there is hostility.. I am just trying to explain that encoding is not encrypted.. And your not actually hiding that CN from anyone by renaming the cert or config file or whatever it is your taking the time to rename so it doesn't match the CN.. Since the CN is there for anyone to view that has access to the file.. Be it they ETs skill or not.. If they know anything about how openvpn works….

So if your going to do a check that the username has to match the CN then not having the CN/Username pop up in the openvpn gui makes no difference. What making sure the the username matches CN for is that Billy doesn't access the vpn with Susan's username and password.. If they have billy's cert then they have to know billys password along with having the cert.

The 2FA comes from having to have the cert and knowing the password. Knowing the username does not remove the 2nd Factor.. There is still something you have and something you know.

enforcematch.png_thumb

billycertcn.png_thumb

coffeecup25

@johnpoz:

"It's still unreadable. "

It is still readable.. And the common name on the cert is still .2 seconds to pull out of the encoded cert.. If you want to use a different user name for the account the user has to know that is different than the common name on the cert that is one thing. But don't think your creating any extra security by just renaming the cert from johnpoz to john. The CN of johnpoz is still in the cert and easy to view.

If your server is set up (box checked) for common name to match certificate

For example, pfSense names the file and the certs with the user id. Rename them and edit config with the new names. It's a little tedious but nobody knows your name if you do it.

Your talking about the attached check box right - see attached.

The point trying to get across to you is even if you rename the cert or config file so it doesn't have the user name on it - its still in the CERT file, while sure grandma can not read it.. But anyone else could with the simple url I posted..

So here is test cert I created.
-----BEGIN CERTIFICATE-----
MIIEfTCCA2WgAwIBAgIBDDANBgkqhkiG9w0BAQsFADByMQswCQYDVQQGEwJVUzEL
MAkGA1UECBMCSUwxEzARBgNVBAcTClNjaGF1bWJ1cmcxDTALBgNVBAoTBEhvbWUx
IDAeBgkqhkiG9w0BCQEWEWpvaG5wb3pAZ21haWwuY29tMRAwDgYDVQQDEwdvcGVu
dnBuMB4XDTE3MDMyODE5Mjc1MFoXDTI3MDMyNjE5Mjc1MFowbDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAklMMRMwEQYDVQQHEwpTY2hhdW1idXJnMQ0wCwYDVQQKEwRI
b21lMRwwGgYJKoZIhvcNAQkBFg1CaWxseUBib2IuY29tMQ4wDAYDVQQDEwViaWxs
eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPIcgUzTlfDQSh9mPo5h
JtLT1p6GGteyhmFB5BuOxZst5455TVvLXYtAN9Vv5mgHaU/CNETT9IesNotD3X+6
v0nYedWBfF5/qrie8YEx3AWaKkmjytNnEMC9WizhPsBOz5BKX2RjYV2gWIB0lrMn
aivnSOk2y4Cgj+uplB40zutThVeXbF6/4YdfLIIB/sFgTD0x31praFeMdI9sfLhL
JhvIdN7sNP1A4Kh06CQDfWonPXjY1AcxF03U7qUh1Y5KEcsoxq9wyiE/wPfI/K7U
shXDIM0jCn4TD3nKU0GY1UzKxX05mf2v1y4jo2RfASX2gLXgjdHv9oBod+Rulkae
MfkCAwEAAaOCASIwggEeMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMDEGCWCGSAGG
+EIBDQQkFiJPcGVuU1NMIEdlbmVyYXRlZCBVc2VyIENlcnRpZmljYXRlMB0GA1Ud
DgQWBBTwSRxt0Aa8iQbQEl67QIqsiqsVsjCBnAYDVR0jBIGUMIGRgBTp/c2QgDww
c2urH9gAH3FdxRH3wqF2pHQwcjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAklMMRMw
EQYDVQQHEwpTY2hhdW1idXJnMQ0wCwYDVQQKEwRIb21lMSAwHgYJKoZIhvcNAQkB
FhFqb2hucG96QGdtYWlsLmNvbTEQMA4GA1UEAxMHb3BlbnZwboIBADATBgNVHSUE
DDAKBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAUFMFWbpZgDfeYM5yX/tE
Gv0tShiSfwvgxyFzyM2QgwbqAsRQgsEs6buCa9TzOs3DICALaVCa9WjB5XrnN7+E
yokE0QM2UvOdPUYPR3I6sum/8Jog2kNzKMfme6nIIMJASUPWRBPnlgXV3bUXrso1
pSjU3OfTM8CO+I6rsLsv03c2ViOltdC1XPXEeEXgk5vxNxHkCB7HgztRSV/8RA2J
JpHPz3kZEo28gqlO+Pi6XFyaAe+UJBhwBoJ92X8L2B+xD0BH4EHSsIXB/HEZg0RQ
48QtBpqxQWtZtJwxr/RnSBKFPIOAj2NZHxPce7vJS/zGOQVAVCyPQD7/ht8v5Fry
og==
-----END CERTIFICATE-----
I can call/rename this cert anything I want.. So sure pfsense calls it say

pfsense-TCP-443-billy.p12

that p12 has the cert in it, can be de-encoded and show you the CN or username that has to match. Your just causing yourself extra work if you think this is adding security from anyone other than say your grandma.

Not sure where you think there is hostility.. I am just trying to explain that encoding is not encrypted.. And your not actually hiding that CN from anyone by renaming the cert or config file or whatever it is your taking the time to rename so it doesn't match the CN.. Since the CN is there for anyone to view that has access to the file.. Be it they ETs skill or not.. If they know anything about how openvpn works….

So if your going to do a check that the username has to match the CN then not having the CN/Username pop up in the openvpn gui makes no difference. What making sure the the username matches CN for is that Billy doesn't access the vpn with Susan's username and password.. If they have billy's cert then they have to know billys password along with having the cert.

The 2FA comes from having to have the cert and knowing the password. Knowing the username does not remove the 2nd Factor.. There is still something you have and something you know.

Oddly enough, a surprising number of people other than grandma wouldn't know this. 30 seconds of work adds an extra layer of security. Then come the password(s).

johnpoz

"30 seconds of work adds an extra layer of security. "

Sorry it doesn't - that is not how security works in IT..

Let me guess you also hide your SSID or don't broadcast it and use mac address filtering.. Since they are added layers of security? ;) Do you also turn off your dhcp server as another layer?

But yeah those keep grandma from hacking your wifi ;)

coffeecup25

@johnpoz:

"30 seconds of work adds an extra layer of security. "

Sorry it doesn't - that is not how security works in IT..

Let me guess you also hide your SSID or don't broadcast it and use mac address filtering.. Since they are added layers of security? ;) Do you also turn off your dhcp server as another layer?

But yeah those keep grandma from hacking your wifi ;)

No, I stand by my answer. The snark is irrelevant. Making something a little more difficult is good planning. The real security is not impaired if some nuisance security is tossed into the mix. It just makes brittle snobs all huffy.