two certificates with the same domain name - jboss

I have added two certificates into my server's(jboss) keystore with domain name in both as "localhost". So now if a local client accesses the server which of the certificates will be sent to the client.
There is no error thrown in jboss, and it is working fine. I just want to know how jboss is choosing which certificate to send?
Listing the contents of the truststore used by java program.
Your keystore contains 2 entries
tomcat, 5 Mar, 2012, trustedCertEntry,
Certificate fingerprint (SHA1): B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:
AB:28:E1:1E
tomcat1, 6 Mar, 2012, trustedCertEntry,
Certificate fingerprint (SHA1): C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:
DD:23:97:87
both tomcat and tomcat1 have the cn=localhost
Listing the contents of the keysttore used by jboss.
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
tomcat, 5 Mar, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:
AB:28:E1:1E
tomcat1, 6 Mar, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:
DD:23:97:87<br>
Displaying the keystore entry using th keytool's list "-v" option asper Kevin's request.
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
Alias name: tomcat
Creation date: 5 Mar, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost
Issuer: CN=localhost
Serial number: 5aaac34c
Valid from: Mon Mar 05 15:04:46 IST 2012 until: Sun Jun 03 15:04:46 IST 2012
Certificate fingerprints:
MD5: 6A:9D:10:37:4F:98:7F:85:D5:93:95:CC:C3:84:07:D8
SHA1: B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:AB:28:E1:1E
SHA256: FB:F5:BC:9F:17:E9:28:8C:77:1B:40:17:8B:D3:12:71:05:0D:CF:9C
99:00:C4:25:76:46:CE:E0:0C:E6:6B
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: F6 B3 2E B5 A0 76 78 7E 9D B6 2A D6 4A 6A 8D 96 .....vx...*.Jj..
0010: FA 7D 47 9B ..G.
]
]
*******************************************
*******************************************
Alias name: tomcat1
Creation date: 6 Mar, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost
Issuer: CN=localhost
Serial number: 4891416
Valid from: Tue Mar 06 06:41:21 IST 2012 until: Mon Jun 04 06:41:21 IST 2012
Certificate fingerprints:
MD5: B9:31:FE:75:E9:28:E6:BC:F2:94:60:93:7B:0C:00:63
SHA1: C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:DD:23:97:87
SHA256: 58:7B:D3:A1:2C:8E:C1:C9:26:0A:9F:A1:86:D1:79:76:34:D2:83:6A
88:0C:E1:36:F5:88:3F:DC:F7:D7:89
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: F1 BF 69 B4 CA D6 9E 72 AC C3 26 9F CD 57 58 7A ..i....r..&..WXz
0010: 62 19 8B B8 b...
]
]
*******************************************
*******************************************

By default, JBoss (or Apache Tomcat) will use the default settings the default X509KeyManager to choose which certificate to use: it will pick the first one it finds in the keystore that is valid for the type of key (e.g. RSA for an RSA-based cipher suite) and at the time of connection.
Failing that, if an alias is explicitly specified in keyAlias, it will pick the certificate in that alias (and it will fail if the key type isn't correct).
If, instead of this, the name of a custom class implementing SSLImplementation is given in the SSLImplementation attribute, it will be used to provide the SSLSocketFactory (so the alias choice will be done however its SSLContext/KeyManager is configured).
Support for Server Name Indication (SNI), which is what would allow the key manager to use the requested host name to help make a choice, was only introduced in Java 7, and only on the client side, so the JSSE cannot use it on the server side currently.

What exactly are you trying to achieve ? The certs are stored in the keystore and presented to the user based on hostname match. This is incorrect, please see below.
Logically speaking it would load only one of these which in turn will be served to the user.
--Edit--
Trying to simplify by pointing to another link
Say you specify "keyAlias" in your jboss configuration to "tomcat" ; then the tomcat alias will be picked up
If you do not specify an alias then the "first key read in the keystore will be used"

Related

Payara ssl certificate and eclipse console

I have a problem for 2 days with eclipse console for payara that is not working anymore.
After I restart the server the only thing that is displayed is:
2018-08-25T05:28:01.959+0000|Info: Running Payara Version: Payara Server 4.1.2.174 #badassfish (build 192)
2018-08-25T05:28:01.961+0000|Info: Server log file is using Formatter class: com.sun.enterprise.server.logging.ODLLogFormatter
2018-08-25T05:28:02.587+0000|Info: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2018-08-25T05:28:02.594+0000|Info: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2018-08-25T05:28:02.599+0000|Info: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
2018-08-25T05:28:02.694+0000|Info: Authorization Service has successfully initialized.
2018-08-25T05:28:02.776+0000|Info: Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry
2018-08-25T05:28:02.809+0000|Info: Grizzly Framework 2.3.31 started in: 86ms - bound to [/0.0.0.0:8080]
2018-08-25T05:28:02.937+0000|Info: Grizzly Framework 2.3.31 started in: 24ms - bound to [/0.0.0.0:8181]
2018-08-25T05:28:02.954+0000|Info: Registered fish.payara.ha.hazelcast.store.HazelcastBackingStoreFactoryProxy for persistence-type = hazelcast in BackingStoreFactoryRegistry
2018-08-25T05:28:02.956+0000|Info: Registered Hazelcast BackingStoreFactory with persistence-type = hazelcast
2018-08-25T05:28:03.027+0000|Info: Grizzly Framework 2.3.31 started in: 14ms - bound to [/0.0.0.0:4848]
2018-08-25T05:28:03.154+0000|Info: Grizzly Framework 2.3.31 started in: 6ms - bound to [/0.0.0.0:3700]
2018-08-25T05:28:03.356+0000|Info: Created HTTP listener http-listener-1 on host/port 0.0.0.0:8080
2018-08-25T05:28:03.364+0000|Info: Created HTTP listener http-listener-2 on host/port 0.0.0.0:8181
2018-08-25T05:28:03.367+0000|Info: Created HTTP listener admin-listener on host/port 0.0.0.0:4848
2018-08-25T05:28:03.417+0000|Info: Created virtual server server
2018-08-25T05:28:03.421+0000|Info: Created virtual server __asadmin
2018-08-25T05:28:03.756+0000|Severe: The SSL certificate has expired: [
[
Version: V3
Subject: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 1024 bits
modulus: 135786214035069526348186531221551781468391756233528066061569654028671100866720352830303278016129003918213826297308054231261658522889438712013757624116391437358730449661353175673177742307421061340003741057138887918110217006515773038453829253517076741780039735595086881329494037450587568122088113584549069375417
public exponent: 65537
Validity: [From: Sat Aug 22 16:41:51 GMT 1998,
To: Wed Aug 22 16:41:51 GMT 2018]
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
SerialNumber: [ 35def4cf]
Certificate Extensions: 7
[1]: ObjectId: 1.2.840.113533.7.65.0 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 0D 30 0B 1B 05 56 33 2E 30 63 03 02 06 C0 ..0...V3.0c....
[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
]
]
[3]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
[4]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[CN=CRL1, OU=Equifax Secure Certificate Authority, O=Equifax, C=US]
Despite the fact that Payara log (server.log) is populated after this with details, eclipse console not.
The used woraround was to use a tail -f server.log
PS: that happens to everybody in the office. So I guess it's something related with payara ssl expired certificate.
I'm using:
Payara Server 4.1.2.174 #badassfish (build 192) and Eclipse Java EE IDE for Web Developers. Version: Oxygen.3a Release (4.7.3a) Build id: 20180405-1200
I think You can simply remove the failing certificate from the keystore. For me the failing certificate had alias: equifaxsecureca and was stored in cacerts.jks
I used the following command:
keytool.exe -delete -alias equifaxsecureca -keystore cacerts.jks -storepass <your pass>
BTW. There is also another one that is failing: gtecybertrustglobalca

GoDaddy Kernel Mode Driver Signing - System error 577

I am new to windows drivers and the signing procedure that's required for production use.
I recently purchased a GoDaddy Driver Signing Certificate and they ensured me that it should be working for kernel mode drivers, however I can not seem to be able to make it work.
After compiling I sign the .cat file with signtool with this command:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" sign /n "COMPANY_NAME" /t http://timestamp.verisign.com/scripts/timstamp.dll mydriver.cat
This finishes successfully and I verify the certificate with this command:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" verify /kp /v mydriver.cat
The output of the above commands states that is successful. You can see the output below
Verifying: mydriver.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): AB24DC3601D29CE37CC2611EDEB7C8E3FBD89D04
Signing Certificate Chain:
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Thu Jun 29 19:06:20 2034
SHA1 hash: 2796BAE63F1801E277261BA0D77770028F20EEE4
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: <COMPANY_NAME>
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
The signature is timestamped: Sat Jul 25 11:37:02 2015
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 01:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 01:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Wed Dec 30 01:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Sun Aug 27 19:48:23 2023
SHA1 hash: D9612472EF0F2787E2B2D9E063A06B32FA5E333D
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: <COMPANY_NAME>
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
Successfully verified: mydriver.cat
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
The cross certificate part seems to be good. I noticed from a similar output I found online (which was signed from GlobalSign) that the Signing Certificate Chain also led all the way up to Microsoft Code Verification Root. Could this be the problem? And if so how would I go about fixing that?
Installing the .inf goes smoothly, but when I start the driver using
net start mydriver
I get the error:
System error 577 has occurred.
Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damage
d, or that might be malicious software from an unknown source.
If I reboot with driver signing enforcement off the above command works fine and the driver works. I have also checked that files in C:\Windows\System32\DriverStore\FileRepository is also signed the same way after installing them.
Does anyone know why the signing does not work, or how I could go about fixing this issue?
Thank you in advance!
I managed to solve my problem, thanks to Ashigore for directing me the right direction.
The problem was related to my intermediate certificates. It seemed like my certificate store was messed up where some intermediate certificates did not have a valid path up to a root CA.
I deleted every certificate that was related to my certificate and started from scratch.
Now the path is correct as:
Microsoft Code Verification Root
Go Daddy Class 2 Certification Authority
Go Daddy Secure Certification Authority
My companies certificate
The Microsoft Code Verification Root was not found at all, and I read somewhere that this certificate is hidden in the kernel somewhere and can not be found be certmgr. However it is possible to install it from microsoft if need be from here http://www.microsoft.com/pki/certs/MicrosoftCodeVerifRoot.crt
I don't think it is necessary tho...
I signed the driver files using these commands:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" sign /v /ac "Go Daddy Class 2 Certification Authority.cer" /n "MY COMPANY" /t http://timestamp.verisign.com/scripts/timestamp.dll mydriver.cat
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" sign /v /ac "Go Daddy Class 2 Certification Authority.cer" /n "MY COMPANY" /t http://timestamp.verisign.com/scripts/timestamp.dll mydriver.sys
New output from verification command:
Verifying: mydriver.sys
File is signed in catalog: kaac.cat
Hash of file (sha1): 0AFAFD987F9C4B1D0BCBBD7851C0EA89AEF413C0
Signing Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Sun Aug 27 19:48:23 2023
SHA1 hash: D9612472EF0F2787E2B2D9E063A06B32FA5E333D
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: MY COMPANY
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
The signature is timestamped: Sat Jul 25 14:14:29 2015
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 01:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 01:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Wed Dec 30 01:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Sun Aug 27 19:48:23 2023
SHA1 hash: D9612472EF0F2787E2B2D9E063A06B32FA5E333D
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: MY COMPANY
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
Successfully verified: mydriver.sys
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

Code Signing Timestamp still expires using Timestamp server

Not sure why, but when using Code Signing using symantec's timestamp server it sets the expiration for the year 2020. This defeats the purpose of using a timestamp server if my program is still going to expire.
Following is the output when using signtool.exe to verify the timestamp application:
Signature Index: 0 (Primary Signature)
Hash of file (sha1): A6F0CEC09F02900D7977C60A87567031D0D96C7A
Signing Certificate Chain:
Issued to: thawte Primary Root CA
Issued by: thawte Primary Root CA
Expires: Wed Jul 16 19:59:59 2036
SHA1 hash: 91C6D6EE3E8AC86384E548C299295C756C817B81
Issued to: Thawte Code Signing CA - G2
Issued by: thawte Primary Root CA
Expires: Fri Feb 07 19:59:59 2020
SHA1 hash: 808D62642B7D1C4A9A83FD667F7A2A9D243FB1C7
Issued to: My Company
Issued by: Thawte Code Signing CA - G2
Expires: Tue Aug 11 19:59:59 2015
SHA1 hash: E45B4CBFBA095DB9465F2371C161EF500201561B
The signature is timestamped: Wed Oct 22 12:15:44 2014
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 19:59:59 2020
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Wed Dec 30 19:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Tue Dec 29 19:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Successfully verified: SetupGoVivoConsole.exe
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
Please note that this certificate is set for 1 year expiry, so it is using a timestamp from the server that Symantec provides. According to the (limited) documentation on this subject, using a timestamp server when signing an application should eliminate the application from expiring after the certificate has expired. According to the information I see above, this is not the case as my application will stop functioning on Tue Dec 29 19:59:59 2020.
The command I am using for signtool is as follows :
signtool.exe sign /f "certificate.pfx" /ac "thawte.crt" /p "mypassword" /t http://timestamp.verisign.com/scripts/timstamp.dll "ExecutableToSign.exe"
The purposes of using time stamping is not to make your signature valid forever. Its purposes it to extend the useful life of your signature, from the usual 1 to 3 years that code-signing certificates are valid, to up to 10 years. This is long enough for most needs -who really thinks their code will be traveling through insecure networks (and therefore in need of code signing)and executing 10 years from now.
A time stamping service does nothing more than signing a hash of your own digital signature, plus the current time (as provided by the time stamping service) with the time-stamping sevice's certificate which they (hopefully) guard a lot better than most users of digital certificates and which has been therefore granted a much longer shelf-life. Long-lived as they are, they are still just digital certificates and for basic security every one of those eventually must expire. Given that computers keep getting more powerful even the most secure algorithms and longest signing keys supported today will eventually be insecure.
Note that the expiration date is nothing more than the longest time a certificate (either your code signing one or the time-stamping one) could be valid for. Even today some time-stamping servers use SHA-1 for signing (e.g. that is what your time-stamping example is using). When that algorithm is no longer trusted (and it shouldn't be too long now), all those SHA-1 time stamps will no longer be trusted. That will happen even if the expiration date hasn't been reached.
You should look into other time-stamping services. There are a few out there that will expire a lot further out and use SHA256
If someone ever comes up with an encryption that can never be broken even as computers get better someone will finally create that "forever" timestamp that you ask for. Don't hold your breath.
Cheers!
I can verify from my painful experience today: an expired timestamp certificate (in my case, Comodo's timestamp cert) will cause Windows (7) to fail the overall code signing check with error 0x80096005.
So yeah, contrary to what's being stated by all cert providers I've looked at, timestamping does not guarantee that your signed executable remains valid in perpetuity.
Look for a timestamp service using a cert. with an expiration date loooong in the future.
According to the information I see above, this is not the case as my application will stop functioning on Tue Dec 29 19:59:59 2020.
Why would it stop functioning? Have you tried it? Try to set date on your computer to 2021 and see what happens. Personally I have not tried it but my colleague did. Windows will still run the program. It will validate the application to the date of signing. TSA server certificate was valid then so it should not be a problem.
If you wouldn't have timestamp on the application's signature that would be a problem. After the certificate of signer expires windows will not run the application. But when using timestamp windows does not care about expiry date of TSA certificate.

Facebook Debugger Not Scraping Page With SSL Certificate

I recently installed a SSL certificate on my domain and now Facebook is unable to scrape my webpages for open graph content.
When I go to https://developers.facebook.com/tools/debug/og/object/ and scrape the site: https://genesispetaluma.com, I get an error "Error parsing input URL, no data was cached, or no data was scraped." When I click to see what the scraper sees, I get a message "document returned no data" at this link: https://developers.facebook.com/tools/debug/og/echo?q=https%3A%2F%2Fgenesispetaluma.com%2F. This worked perfectly before the installation of the SSL Certificate. Because I do not have a wildcard SSL certificate, I tried to scrape a site on my subdomain: http://blog.genesispetaluma.com and this passes and delivers the following information: https://developers.facebook.com/tools/debug/og/object?q=blog.genesispetaluma.com.
I have verified with the server logs that Facebook is making a request to my server: 69.171.237.115 - - [22/Aug/2014:09:44:13 -0700] "GET / HTTP/1.1" 206 6512 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
I ran a test with www.ssllabs.com and it appears that the certificate is installed correctly, with all of the intermediate certificates installed as well. My hosting company has verified that the certificate is installed correctly as well.
Any ideas why this is not working or how I can troubleshoot this? I posted this issue in the Facebook Developer forum and they have not been able to figure it out.
Any ideas why this is not working or how I can troubleshoot this?
There's one small problem that I see that might be causing the problem. The CA certificate is being sent in the chain. The CA certificate is the third certificate shown below.
You should not send the CA in the chain. Rather, the client needs to already have it and use it as a trust anchor.
Another potential issue is that the web app located at https://developers.facebook.com does not use the AddTrust External CA Root certificate as a trust anchor. If Facebook is missing the trust anchor, or does not trust the CA, then there's nothing you can do.
The final potential issue is an SSL/TLS interception proxy is at work. But I doubt Facebook is intercepting the traffic leaving their network.
There's another small problem with the server certificate. The server certificate provides a DNS name in the Common Name (CN). Placing a DNS in the Common Name is deprecated by both the IETF and CA/Browser forums. Though its deprecated, its not forbidden.
DNS names should be placed in the Subject Alternate Name (SAN), and both genesispetaluma.com and www.genesispetaluma.com are there. So that looks OK.
$ openssl s_client -connect genesispetaluma.com:443 -CAfile addtrustexternalcaroot.crt | openssl x509 -text -noout
depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = PositiveSSL CA 2
verify return:1
depth=0 OU = Domain Control Validated, OU = Hosted by A Small Orange LLC, OU = PositiveSSL, CN = genesispetaluma.com
verify return:1
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
86:c2:2e:29:7b:68:f7:f3:16:5d:18:27:84:1f:e4:98
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=PositiveSSL CA 2
Validity
Not Before: Mar 3 00:00:00 2014 GMT
Not After : Mar 3 23:59:59 2015 GMT
Subject: OU=Domain Control Validated, OU=Hosted by A Small Orange LLC, OU=PositiveSSL, CN=genesispetaluma.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:e1:16:f6:78:f8:10:29:e8:96:e6:3b:f1:2f:36:
3f:da:2f:cf:b8:f3:ab:cb:3b:8c:a6:09:0a:a6:3a:
f3:e9:ad:7f:d7:30:c4:ac:b3:9b:98:e0:ec:f0:2a:
75:31:e4:0b:92:76:cc:a3:49:b6:bc:35:77:29:ed:
aa:51:20:b5:c1:b0:1f:ed:ee:23:84:29:99:d4:a2:
6c:c5:5e:66:dc:7e:cf:b7:9d:88:c8:75:1a:46:ec:
ce:34:db:da:06:4e:b0:8d:21:ec:2c:db:88:8e:1f:
9b:13:76:ca:30:8c:4b:60:d5:02:f4:91:a9:d6:b3:
3b:c8:46:2d:0d:90:04:c5:39:ca:e7:e2:20:fe:57:
95:bc:40:9b:af:52:9b:fd:95:54:a6:82:f9:d7:ea:
ac:e5:08:1a:53:c2:7b:59:2b:23:a2:12:41:58:4c:
6c:f0:fe:56:77:ed:ae:0f:9a:5d:b5:32:1c:51:3b:
46:56:d2:60:a4:ad:91:56:11:a6:f4:fc:1b:94:22:
84:9f:a2:c0:80:92:01:48:58:9a:d1:01:11:5f:99:
95:05:c8:18:23:dc:72:e4:d8:01:24:f0:c6:26:23:
be:b3:09:ea:22:94:f6:04:c4:9a:67:3c:15:b1:25:
24:49:7d:60:31:5c:60:a5:f9:7b:65:9d:45:91:fd:
a4:f3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:99:E4:40:5F:6B:14:5E:3E:05:D9:DD:D3:63:54:FC:62:B8:F7:00:AC
X509v3 Subject Key Identifier:
3E:E8:E1:02:B6:36:96:64:7F:9A:84:2E:DD:17:F9:D9:C5:88:A7:EF
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.7
CPS: http://www.positivessl.com/CPS
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.comodoca.com/PositiveSSLCA2.crl
Authority Information Access:
CA Issuers - URI:http://crt.comodoca.com/PositiveSSLCA2.crt
OCSP - URI:http://ocsp.comodoca.com
X509v3 Subject Alternative Name:
DNS:genesispetaluma.com, DNS:www.genesispetaluma.com
Signature Algorithm: sha1WithRSAEncryption
53:20:9f:af:fd:c4:20:78:ed:56:ed:53:8d:29:38:3b:16:00:
ff:7f:39:fd:75:21:b1:d7:af:27:e5:08:d2:c5:77:5e:52:09:
fd:38:ba:03:a3:8c:4d:e9:8f:6e:a7:12:c4:26:b2:1f:02:96:
f8:24:94:0c:c4:74:2a:2d:2e:b4:d6:4c:ee:5f:2d:e1:b6:91:
a3:eb:d0:9a:46:fa:f5:c1:da:a0:13:11:63:56:64:08:e3:f2:
2c:7a:80:19:1f:a1:4e:ae:9e:ab:1e:27:71:ed:55:da:dc:2b:
b0:52:73:ed:e7:1b:c2:2f:5d:6a:17:90:ee:32:b2:36:ee:9c:
8e:57:5b:70:bd:08:55:1c:a2:f4:ca:ee:f4:0b:0e:d7:1a:e3:
e8:de:14:eb:d0:62:24:9a:8b:7c:c6:ab:65:35:e1:5d:a0:2f:
1f:7a:d2:96:e7:0c:12:cc:d8:e7:ff:1c:58:0c:ce:db:6d:cc:
e8:f7:09:17:57:a8:cc:b7:90:4e:f3:0a:2e:d3:56:ad:44:12:
ce:b1:4c:9b:2a:5c:3f:1e:19:95:41:7a:f9:2c:15:c5:48:c6:
bd:49:ad:f6:95:15:21:69:58:a2:0e:c2:9f:9f:c4:a9:d7:83:
a4:6f:5b:07:c5:28:65:8e:fe:fa:83:5f:5f:10:12:36:c8:c9:
f0:55:7a:a0
I tried to scrape a site on my subdomain: http://blog.genesispetaluma.com and this passes
This is odd. The certificate above does not certify blog.genesispetaluma.com. This should fail validation.
If you want to use OpenSSL's s_client to verify the chain, then go to [Root] AddTrust External CA Root and download the AddTrust External CA Root certificate. Then use the CAfile option and you should receive Verify return code: 0 (ok):
$ openssl s_client -connect genesispetaluma.com:443 -showcerts \
-CAfile addtrustexternalcaroot.crt
...
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: A171C87253621808B164BAA1399B07D776E28EBCB8A5AB3A81D65DD66505E3AF
Session-ID-ctx:
Master-Key: 559289812A3602C49FEC4C6FEDC714D4D7B107BDB4E9AD5A811DD0606EF5114D
4DD2624EE141508E92092CF23D946185
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - f4 67 cf 21 46 b8 f9 ae-ba ec da f4 2a 24 9f 5b .g.!F.......*$.[
...
00b0 - b8 97 35 30 cf c6 83 a6-14 a6 b7 16 b1 6c 50 b6 ..50.........lP.
Start Time: 1408754636
Timeout : 300 (sec)
Verify return code: 0 (ok)
Here's the certificate chain with the CA certificate:
$ openssl s_client -connect genesispetaluma.com:443 -showcerts -CAfile addtrustexternalcaroot.crt
CONNECTED(00000003)
depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = PositiveSSL CA 2
verify return:1
depth=0 OU = Domain Control Validated, OU = Hosted by A Small Orange LLC, OU = PositiveSSL, CN = genesispetaluma.com
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=Hosted by A Small Orange LLC/OU=PositiveSSL/CN=genesispetaluma.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
-----BEGIN CERTIFICATE-----
MIIFNTCCBB2gAwIBAgIRAIbCLil7aPfzFl0YJ4Qf5JgwDQYJKoZIhvcNAQEFBQAw
czELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGTAXBgNV
BAMTEFBvc2l0aXZlU1NMIENBIDIwHhcNMTQwMzAzMDAwMDAwWhcNMTUwMzAzMjM1
OTU5WjB+MSEwHwYDVQQLExhEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQxJTAjBgNV
BAsTHEhvc3RlZCBieSBBIFNtYWxsIE9yYW5nZSBMTEMxFDASBgNVBAsTC1Bvc2l0
aXZlU1NMMRwwGgYDVQQDExNnZW5lc2lzcGV0YWx1bWEuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4Rb2ePgQKeiW5jvxLzY/2i/PuPOryzuMpgkK
pjrz6a1/1zDErLObmODs8Cp1MeQLknbMo0m2vDV3Ke2qUSC1wbAf7e4jhCmZ1KJs
xV5m3H7Pt52IyHUaRuzONNvaBk6wjSHsLNuIjh+bE3bKMIxLYNUC9JGp1rM7yEYt
DZAExTnK5+Ig/leVvECbr1Kb/ZVUpoL51+qs5QgaU8J7WSsjohJBWExs8P5Wd+2u
D5pdtTIcUTtGVtJgpK2RVhGm9PwblCKEn6LAgJIBSFia0QERX5mVBcgYI9xy5NgB
JPDGJiO+swnqIpT2BMSaZzwVsSUkSX1gMVxgpfl7ZZ1Fkf2k8wIDAQABo4IBtzCC
AbMwHwYDVR0jBBgwFoAUmeRAX2sUXj4F2d3TY1T8Yrj3AKwwHQYDVR0OBBYEFD7o
4QK2NpZkf5qELt0X+dnFiKfvMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBQBgNVHSAESTBHMDsGCysG
AQQBsjEBAgIHMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cucG9zaXRpdmVzc2wu
Y29tL0NQUzAIBgZngQwBAgEwOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL2NybC5j
b21vZG9jYS5jb20vUG9zaXRpdmVTU0xDQTIuY3JsMGwGCCsGAQUFBwEBBGAwXjA2
BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20vUG9zaXRpdmVTU0xD
QTIuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wNwYD
VR0RBDAwLoITZ2VuZXNpc3BldGFsdW1hLmNvbYIXd3d3LmdlbmVzaXNwZXRhbHVt
YS5jb20wDQYJKoZIhvcNAQEFBQADggEBAFMgn6/9xCB47VbtU40pODsWAP9/Of11
IbHXryflCNLFd15SCf04ugOjjE3pj26nEsQmsh8ClvgklAzEdCotLrTWTO5fLeG2
kaPr0JpG+vXB2qATEWNWZAjj8ix6gBkfoU6unqseJ3HtVdrcK7BSc+3nG8IvXWoX
kO4ysjbunI5XW3C9CFUcovTK7vQLDtca4+jeFOvQYiSai3zGq2U14V2gLx960pbn
DBLM2Of/HFgMztttzOj3CRdXqMy3kE7zCi7TVq1EEs6xTJsqXD8eGZVBevksFcVI
xr1JrfaVFSFpWKIOwp+fxKnXg6RvWwfFKGWO/vqDX18QEjbIyfBVeqA=
-----END CERTIFICATE-----
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIE5TCCA82gAwIBAgIQB28SRoFFnCjVSNaXxA4AGzANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTEyMDIxNjAwMDAwMFoXDTIwMDUzMDEwNDgzOFow
czELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGTAXBgNV
BAMTEFBvc2l0aXZlU1NMIENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDo6jnjIqaqucQA0OeqZztDB71Pkuu8vgGjQK3g70QotdA6voBUF4V6a4Rs
NjbloyTi/igBkLzX3Q+5K05IdwVpr95XMLHo+xoD9jxbUx6hAUlocnPWMytDqTcy
Ug+uJ1YxMGCtyb1zLDnukNh1sCUhYHsqfwL9goUfdE+SNHNcHQCgsMDqmOK+ARRY
FygiinddUCXNmmym5QzlqyjDsiCJ8AckHpXCLsDl6ez2PRIHSD3SwyNWQezT3zVL
yOf2hgVSEEOajBd8i6q8eODwRTusgFX+KJPhChFo9FJXb/5IC1tdGmpnc5mCtJ5D
YD7HWyoSbhruyzmuwzWdqLxdsC/DAgMBAAGjggF3MIIBczAfBgNVHSMEGDAWgBSt
vZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUmeRAX2sUXj4F2d3TY1T8Yrj3
AKwwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAow
CDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0
LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDCBswYIKwYBBQUHAQEEgaYw
gaMwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9BZGRUcnVz
dEV4dGVybmFsQ0FSb290LnA3YzA5BggrBgEFBQcwAoYtaHR0cDovL2NydC51c2Vy
dHJ1c3QuY29tL0FkZFRydXN0VVROU0dDQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRw
Oi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCcNuNOrvGK
u2yXjI9LZ9Cf2ISqnyFfNaFbxCtjDei8d12nxDf9Sy2e6B1pocCEzNFti/OBy59L
dLBJKjHoN0DrH9mXoxoR1Sanbg+61b4s/bSRZNy+OxlQDXqV8wQTqbtHD4tc0azC
e3chUN1bq+70ptjUSlNrTa24yOfmUlhNQ0zCoiNPDsAgOa/fT0JbHtMJ9BgJWSrZ
6EoYvzL7+i1ki4fKWyvouAt+vhcSxwOCKa9Yr4WEXT0K3yNRw82vEL+AaXeRCk/l
uuGtm87fM04wO+mPZn+C+mv626PAcwDj1hKvTfIPWhRRH224hoFiB85ccsJP81cq
cdnUl4XmGFO3
-----END CERTIFICATE-----
2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/OU=Hosted by A Small Orange LLC/OU=PositiveSSL/CN=genesispetaluma.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
---
No client certificate CA names sent
---
SSL handshake has read 4373 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: A171C87253621808B164BAA1399B07D776E28EBCB8A5AB3A81D65DD66505E3AF
Session-ID-ctx:
Master-Key: 559289812A3602C49FEC4C6FEDC714D4D7B107BDB4E9AD5A811DD0606EF5114D4DD2624EE141508E92092CF23D946185
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - f4 67 cf 21 46 b8 f9 ae-ba ec da f4 2a 24 9f 5b .g.!F.......*$.[
0010 - d3 01 c1 21 60 54 8b 1a-8f 5f 5f d5 16 e5 97 11 ...!`T...__.....
0020 - 0f 63 22 5a d3 59 f3 96-a1 3a 35 93 b9 7c 40 9d .c"Z.Y...:5..|#.
0030 - 1d 15 3c 03 04 30 7b 0c-fa fd 69 fc cf ac 32 8c ..<..0{...i...2.
0040 - e2 f2 91 48 37 9b 11 ca-f6 b4 e8 65 5f f2 90 31 ...H7......e_..1
0050 - 8c 2c 7a 74 2e 9a ab de-1f 31 05 b6 a7 6e 42 8b .,zt.....1...nB.
0060 - 6d 36 10 38 38 9f f5 1f-c8 e3 ac ce ba 95 21 4f m6.88.........!O
0070 - 21 3f 38 ef 20 33 f4 b8-86 6a 61 4b e9 cc 00 4d !?8. 3...jaK...M
0080 - ab f3 c6 24 33 3c c5 44-1c 4a f9 71 9b 3c 25 74 ...$3<.D.J.q.<%t
0090 - af 63 73 d7 b3 1b 4f cc-fe 05 76 75 02 db 5b 12 .cs...O...vu..[.
00a0 - 8d 2c 5e 7a 98 ca 95 1c-1a 04 df 6e 22 c3 f2 55 .,^z.......n"..U
00b0 - b8 97 35 30 cf c6 83 a6-14 a6 b7 16 b1 6c 50 b6 ..50.........lP.
Start Time: 1408754636
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
The Facebook team was able to determine the source of the problem. Facebook will not scrape the page unless the og:url has the protocol as well.
For example, this does not work:
meta property="og:url" content="//genesispetaluma.com/"
But this does:
meta property="og:url" content="**https:**//genesispetaluma.com/"
They should to clarify the error in the debugger so people know what's wrong.

MAMP PRO 3x use a symbolic link for htdocs

I'm trying to setup MAMP pro 3 and I have a symbolic link from my Documents folder to /Application/MAMP/htdocs:
lrwxr-xr-x 1 msteudel admin 33 Jun 24 15:11 htdocs -> /Users/msteudel/Documents/wwwroot
In the options for my host I have FollowSymlink checked (I have tried all sorts of various combinations of options from all of them to just symlink):
Screenshot of settings
I'm still getting in my apache error log:
[Tue Jun 24 15:15:00 2014] [error] [client 127.0.0.1] Symbolic link not allowed or link target not accessible: /Applications/MAMP/htdocs
And in the browser getting:
403 Forbidden
You don't have permission to access / on this server.
This all used to work when I was just using the free MAMP.
I tried changing the permissions of the symlink but that didn't work. The group is Admin whereas MAMP might be expecting Staff? I'm not sure that's a problem... I'm on a Mac in case someone missed that.
I also checked that all the folders were set to at least 755...
drwxr-xr-x 5 root admin 170 Oct 23 2013 Users
drwxr-xr-x+ 72 msteudel staff 2448 Jun 24 14:43 msteudel
drwxr-xr-x+ 87 msteudel staff 2958 Jun 23 14:22 Documents
drwxrwxrwx 69 msteudel staff 2346 Jun 23 11:18 wwwroot