openssl s_client -connect www.logoworks.com:443 -showcerts

This shows you every step in which the SSL verification takes place, where the verification fails, etc. Really nifty.

But while you can get the MD5 hash of a file using the “md5″ command (or “md5sum” on Linux), if you want to find the SHA1 or RIPEMD-160 hashes of a file, you can do so with:

openssl sha1 whatever_filename
openssl rmd160 whatever_filename

Also, from this awesome tip from OS X Daily, you can quickly encrypt a file using openssl using the following (I used AES 128 in CBC mode) — it even prompts you for the encryption password (key) twice:

openssl aes-128-cbc -e -in filetoencrypt.txt -out encryptedfilename

and decrypt with:

openssl aes-128-cbc -d -in encryptedfilename -out decryptedfilename

It prompts you for the decryption password once and you’re all set.

I’m still discovering all the goodies inside the OpenSSL command. But so far, it’s proving to be incredibly powerful awesome. I understand it’s the underlying library for SSH, one of the workhorse protocols of the secure internet, but I didn’t know that so much functionality was exposed through the console.

Update: Wow Ok misconception. I thought OpenSSH was based on OpenSSL – it’s not. It’s apparently a common misconception.

One is a Zone. A zone is like the “area” of interest. There are two zones involved in doing this:

• The location of your plugin (the dll files, etc)
• The location of the Word/Excel file being opened (*.doc, *.xls, etc)

These zones usually match up (if your plugin is installed on your computer, and you’re accessing an Office document on your hard drive, both locations are the “My Computer” zone).

For my situation, I had the plugin installed in my computer, but the file being accessed was over an untrusted network share, hence the file was placed in the “Internet” zone.

I had my assemblies in C:\Program Files\InstalledAppDir\*
My Word Doc was in: \\networkserver\sharename\something.doc

It triggered the following error:

The customization does not have the required permissions to execute.

************** Exception Text **************
System.Security.SecurityException: The customization does not have the required permissions to execute.
at Microsoft.VisualStudio.Tools.Applications.Runtime.DomainFactory.CreateDomain(Uri evidenceUri, String domainName, String codeBase, String configFileName, IAddinSecurityManager secman)
at Microsoft.VisualStudio.Tools.Applications.Runtime.AppDomainManagerInternal.CreateCustomizationDomainInternal(Uri uriFullDocumentDirectory, Uri uriFullDocFilePath, String documentName, IHostServiceProvider hostCallback, IAddinSecurityManager secman, AppManifest& applicationManifest, Boolean& manifestDirty, IAppInfo& appInfo)
at Microsoft.VisualStudio.Tools.Applications.Runtime.AppDomainManagerInternal.CreateCustomizationDomain(String applicationDomainPath, String documentName, IHostServiceProvider hostCallback, IExecuteCustomization& executor)
at Microsoft.VisualStudio.Tools.Applications.Runtime.AppDomainManager.CreateCustomizationDomain(String applicationDomainPath, String documentName, IHostServiceProvider hostCallback, IExecuteCustomization& executor)
The Zone of the assembly that failed was:
MyComputer

I followed this guide and tweaked the following policies a little and it now works:

MyComputer zone:
“FullTrust” permissions to the url: C:\Program Files\InstalledAppDir\*
Internet zone:
“Nothing” permission to the url: \\networkserver\sharename
“FullTrust” permissions to the OfficeDocumentMembershipCondition

Make sure you add the membership collection to the internet zone, even if you are accessing a network share. The easiest way to know the zone (and how I found out) is to look at your status bar when you go to the network share. It’ll tell you what security zone that path is seen as.