Can not renew let's Encrypt after install modesecure on nginx (centos7)

Hi experts,
I have a problem with renewing let’s encrypt. I can not renew let’s encrypt after I installed modsecurity module with standalone mode. I’m using reverse proxy nginx with modsecurity module.
Error message when renew
“An unexpected error occurred:
UnicodeEncodeError: ‘ascii’ codec can’t encode character u’\u201c’ in position 2521: ordinal not in range(128)”

I searched non acsii code it bellow

/etc/nginx/nginx.conf: #gzip_disable “MSIE [1-6].(?!.SV1)”;
Binary file /etc/nginx/owasp-modsecurity-crs/.git/objects/pack/pack-0274013405900926f9d9c09157e6fdb19585b6d9.pack matches
Binary file /etc/nginx/owasp-modsecurity-crs/.git/objects/pack/pack-0274013405900926f9d9c09157e6fdb19585b6d9.idx matches
Binary file /etc/nginx/owasp-modsecurity-crs/.git/index matches
/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf:# ├── 932105
/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf:# ├── 932106
/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf:SecRule ARGS_NAMES|ARGS|XML:/
@rx ((?:[~!@#$%^&*()-+={}|:;”'´’‘<>][^~!@#\$%\^&\*\(\)\-\+=\{\}\[\]\|:;\"'´’‘<>]?){12})"
/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf:# ‘ or 1=1#
/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf:# ‘ or 1=1-- -
/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf:# ‘ or 1=1/

/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf:SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES “@rx ((?:[~!@#$%^&*()-+={}|:;”'´’‘<>][^~!@#\$%\^&\*\(\)\-\+=\{\}\[\]\|:;\"'´’‘<>]?){8})"
/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf:SecRule ARGS_NAMES|ARGS|XML:/
@rx ((?:[~!@#$%^&*()-+={}|:;”'´’‘<>][^~!@#\$%\^&\*\(\)\-\+=\{\}\[\]\|:;\"'´’‘<>]?){6})"
/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf:SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES “@rx ((?:[~!@#$%^&*()-+={}[]|:;”'´’‘<>][^~!@#\$%\^&\*\(\)\-\+=\{\}\[\]\|:;\"'´’‘<>]
/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf:SecRule ARGS_NAMES|ARGS|XML:/* “@rx ((?:[~!@#$%^&*()-+={}|:;”'´’‘<>][^~!@#\$%\^&\*\(\)\-\+=\{\}\[\]\|:;\"'´’‘<>]*?){2})"
/etc/nginx/owasp-modsecurity-crs/tests/regression/tests/REQUEST-941-APPLICATION-ATTACK-XSS/941110.yaml: Cookie: <script >alert(1)</script>=value
/etc/nginx/owasp-modsecurity-crs/util/verify.rb:# Copyright © 2012 Diego Elio Petteno

Any idea to fix problem?
Please help me!

1 Like

Hi @daolt

\u201c is the “, Integer Codepoint 8220, one of the additional quotes. So your source code has somewhere that character. Find and remove it. May be you have copied text from Word or from a website.


Unfortunately it is code in modsecurity, if I removed modsecurity module may be not work

1 Like

@erica the “valid grammar for nginx configuration language” plot continues to thicken! (I guess it’s pretty thick already.)

In this case a recipe for blocking certain attacks contains a regular expression that contains non-ASCII characters. :frowning:


@daolt Certbot has always had some trouble with the fact that the configuration language for nginx is not really fully specified anywhere. Therefore it can be difficult for Certbot to predict exactly what can or cannot occur inside of an nginx configuration file.

Although it is technically a bug in Certbot if it doesn’t accept the same configuration files that nginx itself does, this can be hard to fix in a general way without a specification from nginx about exactly what we should accept as valid. I’m not sure that Certbot will be able to offer a fix to this issue anytime soon.

In this case, your configuration is describing how to detect certain malicious web requests that should be rejected as possible attacks against your server. A workaround could be to describe the \u201c quote character in some other way in the configuration rather than presenting a UTF-8 encoded copy of that character. In this case it appears as part of a character class in a regular expression pattern, and probably the regular expression library has some other way to refer to this character with an escaped form. If you don’t know how to do that, you might want to ask the person who wrote this security rule to help create a pure-ASCII equivalent form.


Thanks for explain clearly my problem, I hope Certbot may be fix this issue soon, I’ll try another way. Thanks for contribution for community of your team.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.